Linux Kernel Hardening Checker(github.com)
github.com
Linux Kernel Hardening Checker
https://github.com/a13xp0p0v/kernel-hardening-checker
11 comments
This could be used to see which distro has good defaults and then compare the results.
I wonder how the distros that claim to be "security focused" would fare.
Hardening the kernel against root is DRM-adjacent. I'd hope for a poor score from this tool on any computer I use.
This is also very useful on open source router OS distributions like OpenWRT. There is a fork for my Linksys 32X called "divested"[1] which uses this project to harden the kernel.
[1]: https://divested.dev/
[1]: https://divested.dev/
That's not quite what's happening here. Most of those options protect the general userspace/kernel interfaces and hardware issues (spectre, etc.)
Very few are root specific. And even then you likely do want your VMs (running as root) to not be able to talk to either the host or other VMs. DRM is a very specific flavour of this and I really don't think you want a poor score here.
Very few are root specific. And even then you likely do want your VMs (running as root) to not be able to talk to either the host or other VMs. DRM is a very specific flavour of this and I really don't think you want a poor score here.
From the KSPP recommended settings, I think the following are evil:
> And even then you likely do want your VMs (running as root) to not be able to talk to either the host or other VMs.
I want root in a VM to have full access to that VM's kernel, and that's all that these settings can stop. VMs already can't take over other VMs or the outer system without a vulnerability in the hypervisor.
# Do not allow direct physical memory access (but if you must have it, at least enable STRICT mode...)
# CONFIG_DEVMEM is not set
CONFIG_STRICT_DEVMEM=y
CONFIG_IO_STRICT_DEVMEM=y
# Make sure SELinux cannot be disabled trivially.
# CONFIG_SECURITY_SELINUX_BOOTPARAM is not set
# CONFIG_SECURITY_SELINUX_DEVELOP is not set
# CONFIG_SECURITY_WRITABLE_HOOKS is not set
# Enable "lockdown" LSM for bright line between the root user and kernel memory.
CONFIG_SECURITY_LOCKDOWN_LSM=y
CONFIG_SECURITY_LOCKDOWN_LSM_EARLY=y
CONFIG_LOCK_DOWN_KERNEL_FORCE_CONFIDENTIALITY=y
# Dangerous; enabling this allows direct physical memory writing.
# CONFIG_ACPI_CUSTOM_METHOD is not set
# Dangerous; enabling this allows direct kernel memory writing.
# CONFIG_DEVKMEM is not set
# Dangerous; exposes kernel text image layout.
# CONFIG_PROC_KCORE is not set
# Dangerous; enabling this allows replacement of running kernel.
# CONFIG_KEXEC is not set
# Dangerous; enabling this allows replacement of running kernel.
# CONFIG_HIBERNATION is not set
# Keep root from altering kernel memory via loadable modules.
# CONFIG_MODULES is not set
# But if CONFIG_MODULE=y is needed, at least they must be signed with a per-build key.
CONFIG_MODULE_SIG_FORCE=y
# Disable Model-Specific Register writes.
# CONFIG_X86_MSR is not set
# Turn off kexec, even if it's built in.
kernel.kexec_load_disabled = 1
> And even then you likely do want your VMs (running as root) to not be able to talk to either the host or other VMs.
I want root in a VM to have full access to that VM's kernel, and that's all that these settings can stop. VMs already can't take over other VMs or the outer system without a vulnerability in the hypervisor.
> Do not allow direct physical memory access
This means someone can't plug in a FireWire/pcie/whatever over usb-c device and read/write any data they want (like drive decryption keys).
> exposes kernel text image layout.
This means if you have a partial exploit but don't know where to jump because of address randomisation, the information is leaked.
> Keep root from altering kernel memory via loadable modules.
It means you can't plug in a USB device with a known-vulnerable module that gets auto-loaded and leaves your device open.
All of the cases of root also mean "user action which triggers a root-level service to execute something".
> VMs already can't take over other VMs or the outer system without a vulnerability in the hypervisor.
And if it is vulnerable (or more likely, when it's vulnerable) KSPP is the last layer of defence which can prevent the hypervisor from taking over the system.
There are reason to enable/disable many of those settings, but none of them are evil.
This means someone can't plug in a FireWire/pcie/whatever over usb-c device and read/write any data they want (like drive decryption keys).
> exposes kernel text image layout.
This means if you have a partial exploit but don't know where to jump because of address randomisation, the information is leaked.
> Keep root from altering kernel memory via loadable modules.
It means you can't plug in a USB device with a known-vulnerable module that gets auto-loaded and leaves your device open.
All of the cases of root also mean "user action which triggers a root-level service to execute something".
> VMs already can't take over other VMs or the outer system without a vulnerability in the hypervisor.
And if it is vulnerable (or more likely, when it's vulnerable) KSPP is the last layer of defence which can prevent the hypervisor from taking over the system.
There are reason to enable/disable many of those settings, but none of them are evil.
> This means someone can't plug in a FireWire/pcie/whatever over usb-c device and read/write any data they want (like drive decryption keys).
You're talking about DMA, but that setting is about /dev/mem. They have nothing in common.
> This means if you have a partial exploit but don't know where to jump because of address randomisation, the information is leaked.
But /proc/kcore is only readable by root. If an attacker can read that file, I've already lost.
> It means you can't plug in a USB device with a known-vulnerable module that gets auto-loaded and leaves your device open.
> All of the cases of root also mean "user action which triggers a root-level service to execute something".
If automatic loading is really what you're concerned about, you can disable just it with other settings without having to restrict manual actions by root.
> And if it is vulnerable (or more likely, when it's vulnerable) KSPP is the last layer of defence which can prevent the hypervisor from taking over the system.
That's not how these work. The above settings only affect what root is allowed to do. There are other parts of KSPP that might help with that, but these definitely don't.
> There are reason to enable/disable many of those settings, but none of them are evil.
They're evil because all they do is limit what root can do, which is useful only for tivoization and not real security.
You're talking about DMA, but that setting is about /dev/mem. They have nothing in common.
> This means if you have a partial exploit but don't know where to jump because of address randomisation, the information is leaked.
But /proc/kcore is only readable by root. If an attacker can read that file, I've already lost.
> It means you can't plug in a USB device with a known-vulnerable module that gets auto-loaded and leaves your device open.
> All of the cases of root also mean "user action which triggers a root-level service to execute something".
If automatic loading is really what you're concerned about, you can disable just it with other settings without having to restrict manual actions by root.
> And if it is vulnerable (or more likely, when it's vulnerable) KSPP is the last layer of defence which can prevent the hypervisor from taking over the system.
That's not how these work. The above settings only affect what root is allowed to do. There are other parts of KSPP that might help with that, but these definitely don't.
> There are reason to enable/disable many of those settings, but none of them are evil.
They're evil because all they do is limit what root can do, which is useful only for tivoization and not real security.
Turns out that one is/was(?) a ~%10 perf hit: https://blog.herecura.eu/blog/2020-05-30-kconfig-hardening-t...