How are we going to prevent an attacker from booting another kernel?
E.g. attacker sees the hardened kernel, edits grub config file so it boots the ordinary kernel, reboots and then exploits some vulnerability the hardened kernel would prevent.
Or an attacker could do apt-get remove hardened-vm-kernel && reboot.
This can probably be solved though with the system apparmor profile but I’m not sure if that’s the best approach, especially since an attacker can just use apt-get as that has permissions to remove/update/install the kernel.
Android has a feature called rollback protection which specifically defeats this class of attacks.
Indeed. I don’t see any substitute for verified boot. Anything else will either be limiting features (too much) and even then there might be clever ways to circumvent it.
Debian would likely be very against something like this as it isn’t a major issue like user namespaces and Debian isn’t meant to be a hardened distro. GRKERNSEC_IO disables the ioperm and iopl syscalls which are needed for some things.
Submitting it upstream to Linux is never going to happen. The environment upstream is extremely toxic especially when it comes to hardening patches. That’s why it takes the KSPP so long to upstream a patch.
Sure, it might make sense for a hardened kernel package. Definitely not the default though.
Contributing to linux-hardened might be a good idea as they don’t have patches like these and some things like kprobes are enabled by default in their config.
This is the package you would file tickets against/submit config patches for if you want the work on a minimal kernel to go upstream:
Ideally it’s a matter of figuring out what modules our virtual hardware configurations use and let them know to include it in their next builds. For example shared folders aren’t even recognized because they don;t even consider this usecase for a kernel running in a public cloud so your contributions would be about making this kernel friendly towards desktop users.
VirtualBox modules aren’t even part of it AFAICT, but there’s no reason why they can’t accept it.
On the otherhand the kernel/system bootup is a real speed demon.
I wouldn’t touch the crypto modules because we may not know the full picture about dependencies. May break something critical - it;s a really bad way to shave off a couple more seconds from compile time.
This substantially improves the granularity of CFI by allowing the
compiler to identify that a massive number of functions called be
indirectly called due to never having their address taken.
Would it be possible to use newer kernel sources for this?
There’s tons of new security features in newer kernels like init_on_alloc, init_on_free, safesetid etc. The stable debian kernel has none of these while the sid one does have them.
It would also be great to use a newer GCC as Debian stable’s GCC doesn’t support plugins like stackleak or randstruct.
Backports would be great. Latest version is 5.3 which has all those features.
One thing to be aware of though is that newer kernels often add tons of new attack surface and new vulnerabilities. That’s why grsecurity is using older kernels (4.4 and 4.14). Although, I don’t know how much this will affect us since our kernel disables a lot of things.
It creates a new config option called CONFIG_SECURITY_IO_RESTRICT and disables the iopl and ioperm calls if it’s set. I haven’t yet tested if those calls are blocked, but it should work.