Manage kernel configuration hardening in a separate repository

[tsautereau-anssi]

Many commits from the linux-hardened patchset are fixing Kconfig files in order to change default values for various options. I think that such commits:

• pollute the diff between linux-hardened and upstream Linux;
• are part of an effort that hasn't been maintained, in particular because most new security-relevant Kconfig options haven't been dealt with;
• are not effectively assisting downstream maintainers in properly configuring a linux-hardened kernel;
• are not effectively helping other end-users of the patchset to make neither informed nor truly automatic configuration choices.

For these reasons, I'd really like to get rid of all such commits, but a security-minded kernel configuration definitely remains crucial and utterly relevant to a hardened Linux kernel project. Together with @msalaun-anssi, we thus discussed several ways of improving this situation, among which:

• Introducing a dedicated LINUX_HARDENED Kconfig option which could for instance automatically force-enable other options (e.g. select SECURITY_DMESG_RESTRICT instead of setting default y in config SECURITY_DMESG_RESTRICT) or be used within conditional expressions for other options (e.g. depends on !LINUX_HARDENED, default y if !LINUX_HARDENED, bool "FOO" if EXPERT || LINUX_HARDENED, etc.). The problem is that it doesn't do much in the way of getting rid of Kconfig file patches and can also end up being less flexible for people that want to customize their configuration.
• Using a separate repository for maintaining a set of default and recommended Kconfig options. This work could and should probably be based on similar efforts from KSPP, Alexander Popov and CLIP OS. A tool could then leverage this to help generate a custom but hardened kernel configuration. This would potentially resemble what we have done in this separate CLIP OS repository (see our configsets and the make-config.sh helper script). This may also represent a good opportunity to document those configuration choices, either in another repository (as done in CLIP OS), in the same one (perhaps with some automated generation from comments using Sphinx) or in a wiki.

We think that the second proposition would be the best way to correct the aforementioned issues, and is particularly relevant in light of the upcoming creation of a GitHub organization dedicated to managing the linux-hardened project, since handling several repositories will become easier. I'm therefore creating this issue to gather feedback and keep track of any future work on that matter. Thanks!

[Bernhard40]

This sounds very reasonable.

[anthraxx]

I have been thinking about this for quite a while but for now I'm not sure if I agree. I fully see the points provided here, but in my opinion this project should be more than just feature patches on top of vanilla. This is supposed to be a hardened kernel project which in my humble opinion should also include security by default with an opt-out instead of opt-in approach when it comes to choosing Kconfig options.
I like the LINUX_HARDENED Kconfig enforcing options, but as that's an all or nothing approach, I would still prefer dealing with sane defaults on top of providing the LINUX_HARDENED options and the dedicated options would be touched anyway.
It's not that i don't like CLIP OS approach, i very much do, but on the other hand I'm not sure if I want to make that "mandatory" on top of the kernel sources to achieve something appropriate. CLIP OS itself has a bigger scope and ecosystem around it, for now i really liked that using this repository as kernel source offers your security (including option adjustments) in a self contained way 🤔 What I especially like is the documentation of CLIP OS, so I believe it would be an awesome idea to do something similar to explain hardening options and their default values.

So for now i would suggest the following potential action points:

• find and define saner defaults for Kconfig options that we haven't been dealt with
• introduce a LINUX_HARDENED Kconfig options to force select the whole set of options we strongly recommend
• generate nice docs about Kconfig options and cmdline recommendations etc similar to CLIP OS

[Bernhard40]

The linux-hardened kconfig selection is vastly incomplete so I wouldn't call it self-contained right now. I think dropping those few patches is accepting reality that this project is in maintenance mode and there is no manpower to achieve something better while other active projects exist which are filling that void.

[anthraxx]

I strongly disagree here. The goal is to get this into shape and not to bring it into maintenance mode. Patches are welcome so start contributing config proposals would be a way to bring it into dorm again instead of taking it to the graveyard.

[Bernhard40]

Ok, but dropping kconfigs could help to get more focus on bringing new features. Unlike kconfigs there is already some activity in that part so we can guess this is what people are interested in contributing.

[anthraxx]

I don't see how removing kconfig changes would bring any activity in creating new features, that doesn't correlate with each other. The problem is lack of contributors and not lack of focus.

[tsautereau-anssi]

I have been thinking about this for quite a while but for now I'm not sure if I agree. I fully see the points provided here, but in my opinion this project should be more than just feature patches on top of vanilla. This is supposed to be a hardened kernel project which in my humble opinion should also include security by default with an opt-out instead of opt-in approach when it comes to choosing Kconfig options.

That's exactly why I mentioned a tool that would leverage this separate repository to help generate a custom but still-hardened-by-default kernel configuration, in a simple way. And the fact that this project should be more than just feature patches is truly one of the reasons that make me want to structure things better, making it clearer and easier to use and maintain.

I like the LINUX_HARDENED Kconfig enforcing options, but as that's an all or nothing approach,

That's why I think it's not the solution that should be adopted.

[anthraxx]

I think this is a bit selectively answered, as the following block explains why I believe I currently prefer to see that happening in a central and self contained place. I can just repeat that I like the structuring in CLIP OS src_platform_config-linux-hardware/kernel_config but on the other hand I still believe its more feasible in CLIP OS as the scope is far far beyond a kernel, its a whole operating system with an ecosystem around to build and maintain it.
We "only" have a kernel here and not a whole operating system, moving all kconfig related things out of this place will in my opinion not bring many advantages, however downstream consumers would need to carry the burden by keep a secondary config tool repository in sync with the patchset (used tree version) to achieve something appropriate. A simple make defoldconf won't handle new switches and people would be expected to use additional tooling (which must carefully be kept in sync).
I believe the scope here is a bit more limited and the gain doesn't really justify the scarifies, especially not for an average consumer of the kernel sources.
I also didn't say LINUX_HARDENED should be the only approach, but it may be a neat an additional option to indicate if the strongly recommended set of hardening options is in place or if consumers have deviated from them.

[tsautereau-anssi]

I think this is a bit selectively answered, as the following block explains why I believe I currently prefer to see that happening in a central and self contained place.

Sorry, I just didn't feel it necessary to build on that part as I think the comparison with CLIP OS is not relevant here - I just mentioned it as an illustration.

I can just repeat that I like the structuring in CLIP OS src_platform_config-linux-hardware/kernel_config but on the other hand I still believe its more feasible in CLIP OS as the scope is far far beyond a kernel, its a whole operating system with an ecosystem around to build and maintain it.
We "only" have a kernel here and not a whole operating system,

I don't understand this argument since I don't see how this is related to CLIP OS being more than a kernel. For that matter, we actually chose to have a separate repository for kernel settings precisely because we wanted to help people reuse our hardened kernel for their own projects, independently of CLIP OS. And you said yourself that you want linux-hardened to be more than just a set of patches.

moving all kconfig related things out of this place will in my opinion not bring many advantages, however downstream consumers would need to carry the burden by keep a secondary config tool repository in sync with the patchset (used tree version) to achieve something appropriate. A simple make defoldconf won't handle new switches and people would be expected to use additional tooling (which must carefully be kept in sync).
I believe the scope here is a bit more limited and the gain doesn't really justify the scarifies, especially not for an average consumer of the kernel sources.

I understand your point. Yes, there's probably a little downside. I believe it's worth it though.

[anthraxx]

Maybe its just me, but I still fail to see how removing Kconfig suggestions to sane defaults stops or hinders people from reuse the hardened kernel for their own projects.
Maybe we could start that config maker to play around with it, side by side, and maybe one day I change my mind to remove kconfig changes, but for the time being I still don't see the problem in having it in here on top.

[theLOICofFRANCE]

[RFC] kconfig: add hardened defconfig helpers (2018)
[v2] kconfig: add hardened defconfig helpers