Something useful here?
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
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
Was discussed before. Even an upstream issue was opened. Please search first.
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).
Something useful here?
- https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=919226
- Debian -- Details of package hardening-runtime in buster
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
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
Something useful here? Related to hidepid
?
Doesn’t seem to be anything useful there.
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.
Something we don’t have yet here?
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
?
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.
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]
Outreach done to:
- Debian -- Details of package lockdown in buster
- Debian -- Details of package hardening-runtime in buster
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.