Re: [gentoo-user] Lockdown: free/open OS maker pays Microsoft ransom for the right to boot on users' computers

[BRM]

> From: Michael Mol <mikemol@×××××.com>

> On Sat, Jun 2, 2012 at 8:35 PM, Florian Philipp <lists@×××××××××××.net>
> wrote:
>>  Am 03.06.2012 01:36, schrieb Michael Mol:
>>>  On Sat, Jun 2, 2012 at 6:50 PM, pk <peterk2@××××××××.se> wrote:
>>>>  On 2012-06-02 22:10, Michael Mol wrote:
>>>
>>>  [snip]
>>>
>>  [...]
>>>
>>>  The BIOS will only load a signed bootloader. The signed bootloader
>>>  will only load a signed kernel. The signed kernel will...do whatever
>>>  you tell it to do.
>>>
>>
>>  According to Matthew's blog post, Fedora patched Grub2 and the kernel
> to
>>  avoid loading custom code into them:
>>  - Deactivate grub2 plugins
>>  - Sign all kernel modules and disallow unsigned ones
>>  - Prevent access to PCI through userland
>>  - Sanitize the kernel command line
>
> Yeah, I read his blog post via lwn.net. I forgot some of the details.
>
>
>>
>>>>  What does that mean to a source based "distro"?
>>>
>>>  It's going to make building and installing grub and the kernel
>>>  trickier; you'll have to get them signed. And that's going to
> be a
>>>  PITA for anyone who does developers.
>>>
>>>  What it *really* means is that someone who wants to run Linux as a
>>>  hobbyist or developer is going to disable "SecureBoot", and
> then fall
>>>  back to business as usual.
>>>
>>
>>  Yeah, the only way for Gentoo to have secure boot is a) let each user
>>  register with Microsoft, b) provide a binary kernel and boot loader.
>
> If you have a need to get a secure Gentoo boot, and you don't need to
> boot Windows 8, then (as I understand it) you can also purge the UEFI
> BIOS of Microsoft's key and install your own.

well, on x86 for now...

>
>>
>>>>  Also, I would assume a legitimate key would be able to
>>>>  sign pretty much any binary so a key that Fedora uses could be used
> to
>>>>  sign malware for Windows, which then would be blacklisted by
>>>>  Microsoft...
>>>
>>>  If Fedora allows their key to sign crap, then their key will get
> revoked.
>>>
>>>  What I hope (I don't know) is whether or not the signing system
>>>  involved allows chaining.  i.e., with SSL, I can generate my own key,
>>>  get it signed by a CA, and then bundle the CA's public key and my
>>>  public key when I go on to sign _another_ key.
>>>
>>>  So, could I generate a key, have Fedora sign it, and then use my key
>>>  to sign my binaries? If my key is used to do malicious things,
>>>  Fedora's off the hook, and it's only my key which gets revoked.
>>>
>>
>>  Consider the exact approach Fedora takes: They've only made a certified
>>  stage-1 boot loader. This boot loader then loads grub2 (signed with a
>>  custom Fedora key, nothing chained back to MS) which then loads a
>>  custom-signed kernel. This allows them to avoid authenticating against
>>  MS every time they update grub or the kernel.
>>
>>  This means if you want to certify with Fedora, you don't need to chain
>>  up to MS as long as you use their stage-1 boot loader. However, if I was
>>  part of Fedora, I wouldn't risk my key by signing other people's
> stuff.
>>  Mainboard makers won't look twice when they see rootkits with Fedora
>>  boot loaders.
>
> Yeah, that's not the kind of thing I was thinking about.
>
> With SSL's PKI, someone like StartSSL has a CA cert.
>
> I generate my own key, have StartSSL sign my key. My brother generates
> a key, and I sign his.
>
> Now my brother takes his key and sends you a signed email.
>
> Now, you've never heard of me, and the crypto signature attached to
> that email doesn't mean anything. However, if he bundles my public key
> along with his public key in that email, then you can see that my
> public key was signed by someone you _do_ know. Now you have a chain
> of signatures showing the relationship between that email and the root
> CA.
>
> Now here's the interesting part, and what I was alluding to wrt signed
> binaries and key revocation.
>
> Let's say _my_ key is leaked. My brother send you an email signed with
> his key. You look at that key, you see that key hasn't been revoked.
> You look at the key that signed that key, and you see that _that_ key
> _has_ been revoked. You can then choose to not trust keys signed by
> that key.
>
> Now let's say my _brother's_ key is leaked, and so he revokes it. Any
> new emails signed with that key can be seen to be invalid. However,
> _my_ key is still considered valid; I can still sign things with it.
>
> That's the kind of thing I was thinking about. If you allow key chains
> to be deep, rather than forcing them to be wide, you can wield
> blacklists like a scalpel, rather than a bludgeon.

In theory that's how key signing systems are suppose to work.
In practice, they rarely implement the blacklists as they are (i) hard to maintain,
and (ii) hard to distribute in an effective manner.

Honestly, I don't expect SecureBoot to last very long.
Either MS and the OEMs will be forced to always allow users to disable it,
or they'll be simply drop it - kind of like they did with TPM requirements that were
talked about 10 years back and never came to fruition.

>>>>  and how is malware defined? Anything that would be
>>>>  detrimental to Microsoft?
>>>
>>>  Dunno. I imagine it comes down to whatever the chief key's owner
>>>  doesn't want running on the same hardware while SecureBoot is enabled.
>>>  Rootkits come to mind.
>>>
>>
>>  To quote Matthew:
>>>  If I take a signed Linux bootloader and then use it to boot something
>>>  that looks like an unsigned Linux kernel, I've instead potentially
>>>  just booted a piece of malware. And if that malware can attack
>>>  Windows then the signed Linux bootloader is no longer just a signed
>>>  Linux bootloader, it's a signed Windows malware launcher and
> that's
>>>  the kind of thing that results in that bootloader being added to the
>>>  list of blacklisted binaries and suddenly your signed Linux
>>>  bootloader isn't even a signed Linux bootloader.
>
> What kind of signature is the bootloader checking, anyway?

Regardless of the check, it'll never be sufficient.

Ben