A secure kernel for Debian

@yaperez-anssi @travier-anssi

Hi Yves-Alexis and team. We (Whonix) were working on a hardened-kernel package that aimed to apply both changes from your and Anthraxx’s patchset to an upstream kernel in addition to disabling a variety of commonly unused config options to reduce attack surface (details of what we did documented here [0]). We reached the conclusion that it’s better to unite efforts and minimize NIH as much as possible to make this viable in the long-term and to spread its impact beyond our project as much as possible.

We’ve reached out to Debian’s Ben Hutchings about packaging the patches in Debian. His three conditions were:

  • Its developers should be actively working to get those patches
    upstream.
  • There must be at least someone within the kernel team who takes
    responsibility for maintaining it.
  • It should have regular verifiable releases. (Also, if it isn’t
    updated for a new upstream version, we won’t wait for it but will
    disable building it temporarily.)

Yves you seem to be doing all three and you’re already part of the Debian kernel security team so we were wondering if you please can work with them to provide an optional secure patchset/kernel there. I know that at least us and Tails will opt for it by default. TIA

[0] https://www.whonix.org/wiki/Hardened-kernel
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=934820

Hi @HulaHoop0 and thanks for reaching out. I’m adding @tsautereau-anssi but I’m unsure we should discuss this here considering we’re talking about a Debian feature and not a CLIP OS one.

Patrick already reached out to me in August last year (about https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=934751) and I replied (privately) that I didn’t have enough (personal) time to take the RFP for myself, and things haven’t really evolved.

I’m quite familiar with Ben’s requirements for adding a featureset to the Debian kernel (they were already in place back in time and that’s why I added a new source package for linux-grsec), and I’m unsure linux-hardened would really fit:

  • Point 3 (verifiable releases): I’m unsure how linux-hardened works here (@tsautereau-anssi could comment) but I guess that’d be doable
  • Point 2 (someone in the kernel team taking responsibility): while I’m interested, again I don’t think I have enough time right now
  • Point 1 (upstreaming patches) looks to me the most problematic. The linux-hardened team does a great job of upstreaming things when possible, but I had the feeling that it was accepted that some stuff would never be upstreamed and that it was fine.

By the way, forking the src:linux package to add a featureset is not that hard (see for example what I did back in time for src:linux-grsec) so that’s something Whonix/Tails could do.

I propose that the discussion is done either on #934820 or #934751 depending on which solution you’d prefer in Whonix/Tails.

1 Like

Hello @HulaHoop0,

I’m the maintainer of the CLIP OS kernel and as part of that I participate in linux-hardened development and collaborate with anthraxx (whom I let know about your post here).

In addition to what has been said by @yaperez-anssi:

  • Point 1(upstreaming): Indeed, most if not all patches in the linux-hardened tree were submitted upstream at some point but not merged, for various - good or bad - reasons. With some help or more dedicated time, we may try again for some of these patches, but most are probably never going to land upstream. Moreover, we strongly encourage people contributing patches to linux-hardened to first try to submit them upstream when it makes sense, otherwise we make sure such patches won’t become too much of a burden to maintain by ourselves.
    As for other CLIP OS kernel patches, we also do our best to get them merged upstream (see the current work around O_MAYEXEC for instance).
  • Point 3 (verifiability and responsiveness): anthraxx already signs every single commit, release tag and detached patch set release. Also, linux-hardened updates very closely follow upstream releases.
    We do similarly for all of CLIP OS, including kernel sources.
1 Like

Thanks for both of your feedback. @tsautereau-anssi is it possible for you to provide a deb repo for kernel builds you maintain? We can link our build scripts to fetch the package. This seems like the path of least resistance to obtain a well maintained hardened kernel instead of trying to convince other projects to include the code. I know you are geared towards Gentoo so the basic output of make deb-pkg is enough for us.

Any refinements of tweaks by our team can be pushed to your repo for inclusion. What do you think?

@HulaHoop0 I’m not sure I understand why you’d want us to do that. Isn’t it possible for you to run make deb-pkg from a cloned repository of our sources?

Hi, this is by no means a complete list, but the pros of you guys doing it is:

  • Reproducibility - all downstream projects are using the same package which has a clear auditable trail to your repo (if you guys are using Debian’s reproducible build toolkit/infrastructure).

  • Faster time to binary - You can track new releases much quicker than downstream maintainers and could therefore rapidly make new binaries in event of critical security fixes. I am willing to bet you have faster machines for kernel builds than me :slight_smile:

  • Some unified package versioning policy. Higher version numbers that overrule Debian vanilla but also compatible with their naming to work seamlessly with any dependencies on that platform.