Re: Why don't gnu.org and RMS sign mail? - FDE Crypto

[Florian Weimer]

* Marcel:

> On 11/5/19 4:11 AM, Florian Weimer wrote:
>> The FSF has given out an award in support of Secure Boot-related work,
>> so its approach to the matter is rather ambiguous.
>
> Looking through fsf.org I couldn't find any award in support of "Secure
> Boot" related work, would you mind pointing me to it?

<https://www.fsf.org/news/free-software-award-winners-announced>

It's difficult to argue that the FSF wasn't supportive when it handed
out an award for Secure Boot work.  It also suggests that the issue
has a solution and is therefore manageable.

> The FSF seems to have a very clear position on "Secure Boot" vs.
> "Restricted Boot", and has been running a campaign opposing "Restricted
> Boot" for the best part of this decade:
>
> https://www.fsf.org/campaigns/campaigns-summaries#secureboot

Matthew's work shifted the onus of supporting GNU-compatible Secure
Boot from Microsoft and hardware vendors to GNU/Linux distributions
and was a strategic mistake.

>> I knew this would happen and wrote extensively against Secure Boot.
>> That became a futile exercise when the FSF started supporting it, too.
>
> AFAIK, the only thing the FSF said is that when implemented correctly,
> Secure Boot" is designed to protect the user against malware. They urged
> manufacturers to respect user freedoms when implementing "Secure Boot"
> by doing it correctly.
>
> How you interpret this as support for "Secure Boot"?

Nobody knows what Secure Boot was originally designed to do—and what
its current security objectives are.  I suspect it was initially
intended to save $1.50 for a read-only USB stick, by storing recovery
media on the main storage device.  But even that does not work anymore
because Microsoft opened up the Secure Boot trust root to basically
anyone (who can start their own little company and shell out a few
hundred dollars).  As a result, it no langer means that if it boots,
it's authorized by Microsoft.  The indirect cryptographic chain
GNU/Linux distributions ensures that Microsoft never sees actual
binaries running in ring 0, so they can't do any meaningful
verification on submitted binaries, either.  (The Secure Boot signing
services works by submitting binaries to them, the code signing
certificate you need to purchase does not give you the immediate
ability to run code with Secure Boot active.)

It's also unclear what how this alleged protection against malware
would work when users can easily install their own operating systems.
It's not possible to have it both ways: Either you can replace the
guts of the operating system and you live with the malware risk
(because malware can do the same), or you give up that capability.
User prompts do not really work because they would have to say
something along the line “proceed only if you want to install malware
or GNU/Linux”, which is not politically feasible.  (Also keep in mind
that the Secure Boot work did not deliver anything close to a signed
userspace, and due the lack of ELF signing support in glibc and the
scripted nature of the boot process on mainstream GNU/Linux
distributions, it is unclear how we could deliver that technically.
There is dm-verity and IMA, but that is so draconian that you can't
pretend that the result is still free software with user control, so
it's not used by GNU distributions.)

The main problem I have with the FSF approach to Secure Boot is that
there was a time when we could have killed it, by not supporting it,
and force Microsoft to come up with a different approach to avoid the
obvious anti-trust issues.  The non-copyleft (Tianocore, shim) to
copyleft (GRUB, Linux) signing chain might have been the weakest
point, but through its actions, the FSF has given its approval.  But
we failed to convey that this is a problem that Microsoft has to
solve, and now we have to deal with the fallout.