[meta] Signing linux kernels for other Debian derivatives

[rhertzog]

Hello,

Freexian recently went through the process to get registered with Microsoft to manage its own shim with a Freexian CA embedded (cf #435) to be able to sign the updated versions of grub and linux that we are providing as part of Debian ELTS.

As a service company specialized in Debian, we are also working for other Debian derivatives that would also like to provide secure boot support to their users. Many of them are providing their own Linux kernel for various reasons and this is the sticking point for them since they can't get that modified kernel recognized by Debian's shim.

One solution for them is to go through the whole process (create a signing certificate, and/or a whole CA, setup a safe signing infrastructure, buy an EV cert, get a review from shim-review, get approved by Microsoft, etc.). For many of them, there's quite some learning to do and knowledge to gain to properly manage this over time.

While discussing this with some of our customers, it appeared to me that it would be relatively straightforward for us (Freexian) to help them by reviewing their kernel [1] and then sign their kernels with a dedicated key[2] signed by the Freexian CA. They could then use the shim we have already prepared and get some arrangement with us to get their kernels signed (fortunately that's not very hard for us since our signing infrastructure is integrated in debusine, and it's multi-tenant).

But this opens up a bunch of questions :
(a) is this allowed by the current policies?
(b) what safeguards are needed?
(c) can the signature be automated after an initial review or should each signature be manual with a dedicated review?

Regarding (a), I haven't seen any discussion about the possibility to sign binaries prepared by another organization that the one managing the CA embedded in the shim. But this is what this bug is about, so any feedback is welcome. I do think it has advantages: less complexity for those that don't need more than a signed kernel, fewer shims and fewer signing keys and thus less risk of having something compromised somewhere. It also has disadvantages because it hides from shim-review some organization and some distributions that do leverage secure boot in some way.

Regarding (b), we can possibly try to cover up for the disadvantages identified in (a). For instance, we could say that if any organization signs binaries for others, that relationship should be publicly documented and the initial review of the signed binaries should happen in a public issue tracker (i.e. similar to shim-review). Ideally we would document some reasonable requirements for organizations that perform that kind of third-party binary signing. And failure to meet those requirements can always be sanctioned by Microsoft refusing to sign future shim updates... so that's a big hammer to prevent people from not following the policies that would be set.

Regarding (c), I'm not sure if there's any policy right now but the shim-review process only looks at the kernel once and not for each subsequent kernel release, so I think the same should hold true in that case, and the kernel should be reviewed once only, or possibly once every time that something significant changed (new out-of-tree patch applied, or significant configuration changed, etc.).

Feedback welcome.

[1] The precise things that need to be reviewed in the linux kernel is unfortunately not documented, but we assume that we would have to ensure that the lockdown patches/relevant config options are applied (and that no problematic options are enabled either). And we need to review what changes they make compared to the pristine kernel to try to figure out if some of the changes are unsafe.

[2] The dedicated key helps to ensure that we can easily revoke all signatures if the derivative messed up their kernel in some way.