kernel recompilation for better hardening

Development
,
101

2 posts were split to a new topic: entropy CONFIG_RANDOM_TRUST_CPU yes or no?

102

Btw this kernel doesn’t have to be just a hardened config. We can even port some grsecurity patches from the last public release or apply other patches such as that one which restricts module autoloading.

1 Like
103

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.

GitHub - anthraxx/linux-hardened: Minimal supplement to upstream Kernel Self Protection Project changes. Features already provided by SELinux + Yama and archs other than multiarch arm64 / x86_64 aren't in scope. Only tags have stable history. Shared IRC channel with KSPP: irc.libera.chat #linux-hardening (which was discussed earlier) would be better since that is its own upstream developer and downstream distributions / users.

2 Likes
105

I was thinking of only adding small patches that are split up and easy to look over. e.g. add GRKERNSEC_IO to disable-priv-io.patch.

Obviously we can’t maintain a forward port of all the patches but small ones like GRKERNSEC_IO would be easy to maintain.

The majority of those would be hardware support which aren’t important and can just be ignored in most cases.

1 Like
106

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.

1 Like
107

Can any third party help to review hardened-vm-kernel? Could you submit this to GitHub - anthraxx/linux-hardened: Minimal supplement to upstream Kernel Self Protection Project changes. Features already provided by SELinux + Yama and archs other than multiarch arm64 / x86_64 aren't in scope. Only tags have stable history. Shared IRC channel with KSPP: irc.libera.chat #linux-hardening please?

Could you you please submit this please to Debian or Linux upstream? At least need to see someone else’s feedback.

That’s the idea of verified boot.
(enable Linux kernel gpg verification in grub and/or enable Secure Boot by default)

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.

1 Like
108

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.

1 Like
109

hardened-vm-config:

source code level patches:

1 Like
110

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.

2 Likes
111

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.

2 Likes
112

Should we disable rare and likely unused crypto?

Stuff like “khazad” or “camellia” are unlikely to be used and just take up compilation time.

1 Like
113

https://outflux.net/blog/archives/2019/11/20/experimenting-with-clang-cfi-on-upstream-linux/

It would be great if we could get this working but the changes don’t seem to be available as a patch.

1 Like
114

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.

3 Likes
115
2 Likes
116

Also, if we were to implement CFI, we might want to reconsider disabling modules as it improves CFI effectiveness.

disable module support · GrapheneOS-Archive/kernel_google_crosshatch@8a86770 · GitHub

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.

1 Like
117
1 Like
118
1 Like
119

As per Whonix ™ for KVM, should CONFIG_MEMORY_BALLOON and CONFIG_KSM be disabled?

cc @HulaHoop

2 Likes
120

Yes you can go ahead and disable them.

2 Likes
121

CONFIG_MEMORY_BALLOON is selected by CONFIG_VIRTIO so it can’t be disabled.