Kernel Hardening - security-misc

This guide has some interesting stuff although I’m not sure I’d trust someone to give an informed opinion on security when they’re using leetspeak and saying stuff like “S0rry. I barely use SELinux for reasons. The 1st one is I don’t trust NSA”.

There is some interesting anti-DDoS sysctl settings though which may be helpful.

1 Like

Some of those sysctl settings are useful; I know Whonix has a lot of them by default. Also, Whonix’s iptables rules are great for stopping some attacks the author mentions without having to mess with memory page size and other performance-related setting
I lol’d at his h4ck0rz stuff to

1 Like

Something useful here?

https://wiki.kairaven.de/open/os/linux/tuxsectune

1 Like

There doesn’t seem to be anything that we don’t already do or are working on.

There is a section on /etc/fstab which might be useful for (re-)mount home [and other?] with noexec (and nosuid [among other useful mount options]) for better security? - #15 by Patrick

1 Like

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