grsecurity forums

Hey all,

This topic is a bit offtopic regarding grsecurity but is about security in general within Linux.

The more I read news about the kernel, the more I am concerned about the decision.
In order to improve performance or to _simplify_, features are not pushed inside the kernel itself.
Eg: KMS, netfilter (with a growing number of patch).

However, it makes the kernel bigger and bigger.
And everything running in the kernelland has the maximum privilege.
A sound security would be to process features in the userland as much as possible, and forward result to the kernel.

As a user (selecting option and compiling the kernel), what can I do in order to push to lighten the kernel and use more userland?

Thanks

As a user (selecting option and compiling the kernel), what can I do in order to push to lighten the kernel and use more userland?

To push more things to userland within the currect architecture is a bad idea, imho, as far as it requires more (a priori) vulnerable interfaces between userland and kernelland. For example, with FUSE you could offload some really complicated FS/VFS stuff (like ZFS, for example) to userland, but that require the whole FUSE subsystem in the kernel - the subsystem that has been vulnerable in the past and still contains undisclosed vulnerabilities for sure. So if you don't need FUSE, it's safer not to compile it in.

As a user you can do not much: just disable the options you don't need, so this will make the resulting kernel not to contain some vulnerable code. For example, I compile my production kernels without FUSE, without the Connector subsystem, without ebtables, without IPsec, without SCTP, without LSM, etc. That already made us not vulnerable to any vulnerabilities found it that disabled subsystems, not just public vulns, and also made the rootkit deployment a bit harder for an attacker.

Another recipe is to stick with PaX/x86. It does a bit weaker ASLR for userland processes than PaX/amd64, but has rock solid UDEREF (while UDEREF/amd64 is not that solid, is in early age, so I, personally, would not use it in production before it become mature) and RANDKSTACK (there's no kernel stack randomization for amd64 for now).

OK.

So you advice to lighten the kernel as much as possible with the removal of unneccessary features.
I'll make a deeper inspection in my kernel to see what else I can remove from the config.

But I am doubtful on the kernel strategy to incorporate more and more stuff in kernelland.