Your message dated Thu, 01 May 2025 14:30:37 +0200 (CEST) with message-id <20250501123037.F369ABE2DE0@eldamar.lan> and subject line Closing this bug (BTS maintenance for src:linux bugs) has caused the Debian Bug report #928362, regarding Enable some kernel hardening by default to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact owner@bugs.debian.org immediately.) -- 928362: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928362 Debian Bug Tracking System Contact owner@bugs.debian.org with problems
--- Begin Message ---
- To: "submit@bugs.debian.org" <submit@bugs.debian.org>
- Subject: Enable some kernel hardening by default
- From: "john.pseudonym1" <john.pseudonym1@protonmail.com>
- Date: Thu, 02 May 2019 21:32:52 +0000
- Message-id: <dFd3xkEUeOyHc7ymfHW3vbkKRCkI5igdQZudNN8Urf-b_vfBojROTCHI79kbNs3qvjHLBC7Kq_qsgepJua92RZwodO__h_W9xwDtaY1FeB0=@protonmail.com>
- Reply-to: "john.pseudonym1" <john.pseudonym1@protonmail.com>
Package: linux-image-amd64
Version: 4.19+104
Severity: importantHi,It would be great if Debian included some kernel hardening by default. These settings would offer great security benefits and no or very minimal performance decrease.Setting “kernel.kptr_restrict=1” with sysctl makes kernel symbols in /proc/kallsyms only accessible to root which can make it more difficult for a kernel exploit to resolve addresses/symbols. Setting it to 2 hides the symbols regardless of privileges.
Setting “kernel.dmesg_restrict=1” with sysctl restricts access to the kernel logs which can give an attacker less information on what they can do.
Setting “kernel.unprivileged_bpf_disabled=1” and “net.core.bpf_jit_harden=2” with sysctl hardens the BPF JIT compiler and restricts it to root. It comes with a performance drop on systems that use the JIT compiler a lot but this should only really effect servers.
Setting “vm.mmap_rnd_bits=32” and “vm.mmap_rnd_compat_bits=16” with sysctl improves KASLR effectiveness for mmap. This might break some things but I haven't had anything break on me yet.
Adding “slab_nomerge” as a boot parameter may also be useful. slab_nomerge disables the merging of slabs of similar sizes. Sometimes a slab can be used in a vulnerable way which an attacker can exploit. This may have a slight increase in memory usage.
Mounting /proc with hidepid=2 in /etc/fstab will hide other users’ processes from unprivileged users. This makes it a lot harder for an attacker to get information about other running processes. Some processes (like systemd-logind) will break but you can add exceptions for them.
If Debian could include any of these by default then that would be great.Best Regards.
--- End Message ---
--- Begin Message ---
- To: 928362-done@bugs.debian.org
- Cc: 928362-submitter@bugs.debian.org
- Subject: Closing this bug (BTS maintenance for src:linux bugs)
- From: carnil@debian.org
- Date: Thu, 01 May 2025 14:30:37 +0200 (CEST)
- Message-id: <20250501123037.F369ABE2DE0@eldamar.lan>
Hi This bug was filed for a (very) old kernel or the bug is old itself without resolution. Maybe it was for a feature enablement which nobody acted on. We are sorry we were not able to timely deal with this issue. There are many open bugs for the src:linux package and thus we are closing older bugs where it's unclear if they still occur in newer versions and are still relevant to the reporter. For an overview see: https://bugs.debian.org/src:linux . If you can reproduce your issue with - the current version in unstable/testing - the latest kernel from backports or, if it was a feature addition/wishlist and still consider it relevant, then: Please reopen the bug, see https://www.debian.org/Bugs/server-control for details. Please try to provide as much fresh details including kernel logs where relevant. In particular were an issue is coupled with specific hardware we might ask you to do additional debugging on your side as the owner of the hardware. Regards, Salvatore
--- End Message ---