As scarce entropy in VMs is, we really shouldn’t sacrifice any sources.
Not good, since we don’t have anyone with the skills to maintain these patches in-hose as far as I know. Someone who understands these patches. Any questions could not be answered / security vulnerabilities could not be fixed by us.
Even the modified kernel config seem risky. Worsening entropy could be one catastrophic issue. There are so many kernel config, it’s hard me develop a solid understanding of them. Thousands of such kernel config options. A lot to research. Since these are thousands, seems hard to reason about these and daunting.
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.