Kernel Hardening - security-misc

I can say that this setting works very well in regular Debian Buster.
It is an /etc/fstab line to help protect shared memory

tmpfs /run/shm tmpfs defaults,noexec,nosuid 0 0

You can edit the file directly, or more favourably, if there is such a thing as /etc/fstab.d? you can put it there.

I have not tried it on Whonix but it would probably work

1 Like

Was discussed before. Even an upstream issue was opened. Please search first.

2 Likes
2 Likes

Should go to (re-)mount home [and other?] with noexec (and nosuid [among other useful mount options]) for better security?

We talked about this before when trying to mount /proc with hidepid=2.

TL;DR: We created a few issues upstream and nothing really came of it (yet).

2 Likes

Something useful here?

Package contents:

cat /etc/default/grub.d/01_hardening.cfg

# Linux command line options recommended by the KSPP
# https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project/Recommended_Settings#kernel_command_line_options
GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT kaslr pti=on slab_nomerge page_poison=1 slub_debug=FPZ nosmt"

# Other interesting options are:
# - intel_iommu=on (sometimes intel_iommu=on,igfx_off) for enabing I/OMMU

# When done editing the file, rebuild grub configuration with: update-grub

cat /usr/lib/sysctl.d/10-hardening.conf

# sysctl recommended by the KSPP
# https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project/Recommended_Settings#sysctls

# Try to keep kernel address exposures out of various /proc files (kallsyms, modules, etc).
kernel.kptr_restrict = 1

# Avoid kernel memory address exposures via dmesg.
kernel.dmesg_restrict = 1

# Block non-uid-0 profiling (needs distro patch, otherwise this is the same as "= 2")
kernel.perf_event_paranoid = 3

# Turn off kexec, even if it's built in.
kernel.kexec_load_disabled = 1

# ptrace hardening
# 1: Avoid non-ancestor ptrace access to running processes and their credentials.
# 2: Restrict ptrace access to processes with CAP_SYS_PTRACE
# 3: Completely disable ptrace
kernel.yama.ptrace_scope = 1

# Disable User Namespaces, as it opens up a large attack surface to unprivileged users.
# On Debian kernel.unprivileged_userns_clone is set to 0 by default as well
user.max_user_namespaces = 0

# Turn off unprivileged eBPF access.
kernel.unprivileged_bpf_disabled = 1

# Turn on BPF JIT hardening, if the JIT is enabled.
net.core.bpf_jit_harden = 2

# On x86_64 this adds some bits to userspace ASLR
# vm.mmap_rnd_bits=32

# If all relevant modules have been loaded in the initramfs (by listing them in
# /etc/initramfs/modules and rebuilding the initramfs with update-initramfs,
# one can completely disable modules loading with:
# kernel.modules_disable=1

2 Likes

No, it’s just stuff we’ve already enabled or unneeded things. Some of these options are defaults so I don’t know why they’re in this package.

kaslr

KASLR is enabled by default in Debian and most other distros.

kernel.perf_event_paranoid = 3

This is a default in Debian and requires a kernel patch so we can’t set it in security-misc for other distros since they might not have the patch.

user.max_user_namespaces = 0

Disabling user namespaces entirely will break many sandboxing applications and won’t give any benefit. User namespaces do add a lot of attack surface for privilege escalation but as Debian disables it for unprivileged users by default with a kernel patch, disabling them entirely is pointless.

If all relevant modules have been loaded in the initramfs (by listing them in /etc/initramfs/modules and rebuilding the initramfs with update-initramfs, one can completely disable modules loading with:

This is interesting though. It might be another way to load kernel modules for enforce kernel module software signature verification [module signing] / disallow kernel module loading by default

2 Likes

Something useful here? Related to hidepid?

1 Like

Doesn’t seem to be anything useful there.

1 Like

This is a good presentation on how many bugs the Linux kernel has and is why kernel hardening is so important.

TL;DR: Hundreds of bugs are found every month with fuzzers.

1 Like

A post was split to a new topic: Disabling TCP SACK, DSACK, FACK

Something we don’t have yet here?

1 Like

New warning in journal:

Sep 14 08:14:14 host systemd[1]: Failed to bump fs.file-max, ignoring: Invalid argument

Possible cause:

I am not sure above bug is only a symptom. I don’t think we changed fs.file-max?

1 Like

I’ve looked through it before and I don’t think there’s anything useful to us.

Yes, /etc/sysctl.d/anonymizer-config-gateway.conf changes it although it’s nothing to do with kernel hardening.

1 Like

Interesting conclusion about syzbot in the Linux Plumbers conference attended by a Debian kernel maintainer

Q: How often does this catch bugs in the distro kernel?

A: It doesn’t often catch new bugs but does catch missing fixes and regressions.

Q: Is anyone checking the syzkaller test cases against backported fixes?

A: Yes [but it wasn’t clear who or when]

2 Likes
2 Likes
2 Likes

Outreach done to:


(as per enforce kernel module software signature verification [module signing] / disallow kernel module loading by default - #47 by Patrick)

2 Likes

Could we please work on the presentation of package security-misc?

Contributions / suggestions for README.md?
Github description, github website, githab tags?

Technical implementation is good but presentation might be lacking and outreach and popularity of security-misc is almost non-existing.

Once that is done, we could notify related parties of the existence of this package and add to relevant lists.

2 Likes

Should review generally which systemd target pulls services. Some services make much more sense (better security) when run during sysinit target before anything else that might get exploited later on (desktop environment, browser, web servers, etc.)

1 Like

Quote Lennart Poettering (systemd developer) said in 2014

Sorry, but we simply don’t support hidepid= as it is implemented right now in the kernel. We need to be able to get meta data out of /proc for clients. journald needs that, polkit, does, our apis do that, there’s probably a lot more.

hidepid= is a bit naive there.

I’d actually like to support it better, but if we do that I figure we need some kernel changes first. instead of being a kernel-wide setting it should be a per-mount point setting, so that we can turn it on for some services, and turn it off for others, simply by passing different settings to the procfs in their respective mount namespaces.

Anyway, the way it stands now, we cannot support this. Sorry.

That quote is a bit old. Things may or may not be better by now.

1 Like