[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: shim-signed (was: Firmware - what are we going to do about it?)



Moin

On Tue, Apr 26, 2022 at 04:14:02PM +0200, Marc Haber wrote:
> On Sat, 23 Apr 2022 18:21:47 +0100, Steve McIntyre <steve@einval.com>
> wrote:
> >We don't have good docs around this in general (hey, it's security
> >software - it's against the law to write good and complete docs!), but
> >I've certainly discussed this with a few folks over the years.
> It would be great to have that written down somewhere to tell poeple
> what they're actually doing.

Something like https://wiki.debian.org/SecureBoot?

> >Alternatively, people can build replacement shim-signed packages using
> >their own root of trust if desired. If we had a large enough number of
> >users wanting a different root of trust, we could even offer our own
> >different shim-signed package to match.
> I would probably prefer to have grub an/or the kernel signed, avoiding
> additional code, but maybe having some explanation would convince me
> that the shim actually improves things additionally to adding
> complexity.

All the UEFI parts (GRUB, kernel) and also the kernel modules _are_
signed.  Otherwise this whole stunt would be kind of useless.

However, secure boot signing process at Microsoft is a review-sign
process, aka you send the binary to the authority and get a signature
back.  They don't provide a signed certificate, which you could use to
sign stuff at will, as you would do with an e-mail (to be exact, S/MIME
and secure boot uses the same signature format).

So it is simply not possible with the existing process, to sign
everything with it.  So shim was introduced, which is signed using the
review process, and adapts the signing to accept signatures done by
another CA, which is controlled by Debian and used to sign everything.

Regards,
Bastian

-- 
Extreme feminine beauty is always disturbing.
		-- Spock, "The Cloud Minders", stardate 5818.4


Reply to: