Re: shim-signed (was: Firmware - what are we going to do about it?)
Marc Haber wrote:
>On Fri, 22 Apr 2022 11:16:42 +0200, Philip Hands <phil@hands.com>
>wrote:
>>I understand the urge to insist upon absolute DFSG purity in the media
>>we produce, but when it comes to wanting to avoid every last shred of
>>data that we could not regenerate ourselves, I think we crossed that
>>line some time ago.
>>
>>I'm thinking of shim-signed, which is included in our official media.
>>
>>Despite being free software in source form, it is signed by Microsoft,
>>and can only be expected to work with that signature ... which we cannot
>>create.
>>
>>On most (all?) hardware one is able to avoid UEFI secure-boot, so won't
>>need to use shim-signed, but I'd imagine that some hardware insists on
>>secure-boot, or the opt-outs are somehow broken and so is not usable
>>without shim-signed.
>
>Excuse me for asking a user question on -devel, but do we have any
>docs where someone explains how much a security trade off is
>shim-signed relativ to the optimum? I think that using shim-signed is
>surely worse than a directly signed kernel, but I don't know whether I
>can tell my system (or shim-signed?) to accept MY or Debian's signed
>kernel without the Microsoft intermediate signature, and whether this
>is any more secure than running an encrypted system without secure
>boot at all.
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.
Fundamentally, shim is a compromise. It lets us use an existing root
of trust (that's already installed on the vast majority of x86
machines) to bootstrap our own secure setup.
If you don't like the fact that Microsoft's keys are involved. it's
possible on a lot of machines to enrol your own keys and remove
Microsoft's entirely. If you go that way, you could absolutely sign
grub and/or the kernel directly. But that's not something that's easy
to do - it's not likely to work well for the vast majority of users.
Running an encrypted system without secure boot *at all* is a
difficult thing to support well. The entire point of SB is that the
firmware can use keys to validate the next stage in the boot
process. An *encrypted* kernel stops other people logging in to your
system, but it does not give you protection against somebody tampering
with the system behind your back and doing a MitM attack.
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.
...
>>If not, is the problem having other blobs of data on the media that we
>>also cannot generate, or is it the licensing of that data, or something
>>else?
>
>We can compile shim-signed and compare the signed code with our own
>object code, can't we? That we we would only have to worry about the
>validity and benignness of the signature and not worry about having
>undocumented functionality in the signed code.
Better than that, our shim-signed source package always double-checks
things here. At build time it removes the Microsoft signature and
compares that shim binary to the binary that we submitted for
signing. We would spot immediately if there was any code added.
--
Steve McIntyre, Cambridge, UK. steve@einval.com
"We're the technical experts. We were hired so that management could
ignore our recommendations and tell us how to do our jobs." -- Mike Andrews
Reply to: