[GIT PULL] Load keys from signed PE binaries

[GIT PULL] Load keys from signed PE binaries

[David Howells]

Hi Linus,

Can you pull this patchset please?

It provides a facility by which keys can be added dynamically to a kernel that
is running in secure-boot mode.  To permit a key to be loaded under such a
condition, we require that the new key be signed by a key that we already have
(and trust) - where keys that we "already have" could include those embedded in
the kernel, those in the UEFI database and those in cryptographic hardware.

Now, "keyctl add" will already handle X.509 certificates that are so signed,
but Microsoft's signing service will only sign runnable EFI PE binaries.

We could require that the user reboot into the BIOS, add the key, and then
switch back, but under some circumstances we want to be able to do this whilst
the kernel is running.

The way we have come up with to get around this is to embed an X.509
certificate containing the key in a section called ".keylist" in an EFI PE
binary and then get the binary signed by Microsoft.  The key can then be passed
to the kernel by passing the signed binary:

	keyctl padd asymmetric "" {ID of .system_keyring} <pekey.efi.signed

This command executes the following steps:

 (1) Parse the PE binary to locate the signature and the new key.

 (2) Parse the PKCS#7 message in the PE binary.

 (3) Parse the content of the PKCS#7 message which is in "Microsoft individual
     code signing form" (the mscode bits in my patches).  This contains the PE
     binary digest type and the expected resultant digest value.

 (4) Digest the signed parts of the PE binary and compare the digest obtained
     to the digest expected (obtained in step (3)).

 (5) Digest the signed parts of the PKCS#7 message (which covers the content
     data used in step (3)).

 (6) Verify the signature on the PKCS#7 message against one of the X.509
     certificates it contains.

 (7) Check the signatures on the chain of X.509 certificates in the PKCS#7
     message as far as possible.

 (8) Cross-reference the chain of X.509 certificates against the known keys the
     kernel already possesses, and if one is found, verify the signature of the
     nearest object to the PKCS#7 message that we can (or the PKCS#7 message
     itself) against the trusted key.

 (9) Pass the X.509 certificate embedded in the message to the X.509 parser to
     be turned into a key.

To make this work, step (8) requires access to the .module_sign keyring, so
this is separated from the module code to make the build dependencies simpler.
It is also renamed to .system_keyring as it can then be generic.

To make life easier whilst testing, I got rid of the "extra_certificates" file
and replaced it with a glob that just glues together all the "*.x509" files in
the source and build root directories.

Since this requires the ability to add to .system_keyring, I have had to turn
on WRITE permission for root - but so that _only_ trusted keys can be added,
I've added two more flags in key->flags:

	KEY_FLAG_TRUSTED - this key is trusted.

	KEY_FLAG_TRUSTED_ONLY - only links to trusted keys can be made to this
				keyring.

I'm not sure that this is the best mechanism by which to filter keyring
additions, but it's not currently visible to the user, and so can be changed.
One thing we might want to consider is using X.509 extension fields to contain
bitfields that indicate what is permitted of the key inside an X.509
certificate.  These contribute to the X.509 cryptographic digest and so are
secure.


What these patches then do is allow you to add new keys by signing them with a
key a user will already have.  There can be more than one source for these
keys: firstly, there is a key built into the kernel for module signing
purposes, and secondly, we have patches under development for extracting keys
from the UEFI signature database.


Note: Though we don't actually execute the PE binary container to get at the
key, the binary must be executable in the EFI environment for Microsoft to sign
it.

The test wrapper I'm using is this:

	#include <efi.h>
	#include <efilib.h>

	EFI_STATUS
	efi_main (EFI_HANDLE image_handle, EFI_SYSTEM_TABLE *systab)
	{
		InitializeLib(image_handle, systab);
		Print(L"This program contains a list of public keys.\n");
		return EFI_SUCCESS;
	}

	extern __attribute__((section(".keylist"))) const uint8_t certificate_list[];
	extern __attribute__((section(".keylist"))) const uint8_t certificate_list_end[];
	asm(".section .keylist,\"a\"\n"
	    "certificate_list:\n"
	    ".incbin \"signing_key.x509\"\n"
	    "certificate_list_end:"
	    );

and is built from pekey.c by something like this:

	CPPFLAGS := -nostdinc -I /usr/include/efi -I /usr/include/efi/x86_64

	CFLAGS := -O2 -fpic \
		-Wall -fshort-wchar -fno-strict-aliasing \
		-fno-merge-constants -mno-red-zone

	LDSCRIPT := /usr/lib64/gnuefi/elf_x86_64_efi.lds
	CRT0	:= /usr/lib64/gnuefi/crt0-efi-x86_64.o
	X509	:= magrathea
	KEY	:= /data/modsign/linux-modsign/signing_key.priv

	pekey.efi.signed: pekey.efi
		pesign -i $< -o $@ -c $(X509) -p $(KEY) -s -f

	pekey.efi: pekey.so
		objcopy \
			-j .text -j .sdata -j .data -j .dynamic -j .dynsym -j .rel \
			-j .rela -j .reloc -j .keylist --target=efi-app-x86_64 $< $@

	pekey.so: pekey.o
		$(LD) -nostdlib -T $(LDSCRIPT) -shared -Bsymbolic $(CRT0) $< -o $@ \
			-L /usr/lib64 -lefi -lgnuefi \
			-L /usr/lib/gcc/x86_64-redhat-linux/4.7.2 -lgcc

	pekey.o: pekey.c Makefile
		$(CC) $(CPPFLAGS) $(CFLAGS) -c $< -o $@

Signed-off-by: David Howells <dhowells@redhat.com>
---
The following changes since commit 406089d01562f1e2bf9f089fd7637009ebaad589:

  Merge tag 'trace-3.8-rc3-regression-fix' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace (2013-01-14 20:22:16 -0800)

are available in the git repository at:


  git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-modsign.git tags/pekey-20130221

for you to fetch changes up to 4ea349d3bb1d3521b7df8dbf0e88fe41cd3c0683:

  MODSIGN: Fix including certificate twice when the signing_key.x509 already exists (2013-02-21 14:11:40 +0000)

----------------------------------------------------------------
(from the branch description for devel-pekey local branch)

clone of "master"
signed-pefile contained key

----------------------------------------------------------------
Chun-Yi Lee (1):
      MODSIGN: Fix including certificate twice when the signing_key.x509 already exists

David Howells (27):
      KEYS: Load *.x509 files into kernel keyring
      KEYS: Separate the kernel signature checking keyring from module signing
      KEYS: Add a 'trusted' flag and a 'trusted only' flag
      KEYS: Rename public key parameter name arrays
      KEYS: Move the algorithm pointer array from x509 to public_key.c
      KEYS: Store public key algo ID in public_key struct
      KEYS: Split public_key_verify_signature() and make available
      KEYS: Store public key algo ID in public_key_signature struct
      X.509: struct x509_certificate needs struct tm declaring
      X.509: Add bits needed for PKCS#7
      X.509: Embed public_key_signature struct and create filler function
      X.509: Check the algorithm IDs obtained from parsing an X.509 certificate
      X.509: Handle certificates that lack an authorityKeyIdentifier field
      X.509: Export certificate parse and free functions
      PKCS#7: Implement a parser [RFC 2315]
      PKCS#7: Digest the data in a signed-data message
      PKCS#7: Find the right key in the PKCS#7 key list and verify the signature
      PKCS#7: Verify internal certificate chain
      PKCS#7: Find intersection between PKCS#7 message and known, trusted keys
      Provide PE binary definitions
      pefile: Parse a PE binary to find a key and a signature contained therein
      pefile: Strip the wrapper off of the cert data block
      pefile: Parse the presumed PKCS#7 content of the certificate blob
      pefile: Parse the "Microsoft individual code signing" data blob
      pefile: Digest the PE binary and compare to the PKCS#7 data
      PEFILE: Validate PKCS#7 trust chain
      PEFILE: Load the contained key if we consider the container to be validly signed

 crypto/asymmetric_keys/Kconfig                     |  20 +-
 crypto/asymmetric_keys/Makefile                    |  30 ++
 crypto/asymmetric_keys/mscode.asn1                 |  28 ++
 crypto/asymmetric_keys/mscode_parser.c             | 110 +++++
 crypto/asymmetric_keys/pefile_parser.c             | 479 +++++++++++++++++++++
 crypto/asymmetric_keys/pefile_parser.h             |  36 ++
 crypto/asymmetric_keys/pkcs7.asn1                  | 127 ++++++
 crypto/asymmetric_keys/pkcs7_parser.c              | 326 ++++++++++++++
 crypto/asymmetric_keys/pkcs7_parser.h              |  72 ++++
 crypto/asymmetric_keys/pkcs7_trust.c               | 149 +++++++
 crypto/asymmetric_keys/pkcs7_verify.c              | 260 +++++++++++
 crypto/asymmetric_keys/public_key.c                |  60 ++-
 crypto/asymmetric_keys/public_key.h                |   6 +
 crypto/asymmetric_keys/x509.asn1                   |   2 +-
 crypto/asymmetric_keys/x509_cert_parser.c          |  55 ++-
 crypto/asymmetric_keys/x509_parser.h               |  28 +-
 crypto/asymmetric_keys/x509_public_key.c           | 119 ++---
 include/crypto/public_key.h                        |   9 +-
 include/keys/system_keyring.h                      |  23 +
 include/linux/key-type.h                           |   1 +
 include/linux/key.h                                |   3 +
 include/linux/oid_registry.h                       |   7 +-
 include/linux/pe.h                                 | 448 +++++++++++++++++++
 init/Kconfig                                       |  13 +
 kernel/Makefile                                    |  47 +-
 kernel/modsign_pubkey.c                            | 104 -----
 kernel/module-internal.h                           |   2 -
 kernel/module_signing.c                            |   7 +-
 ...modsign_certificate.S => system_certificates.S} |   7 +-
 kernel/system_keyring.c                            | 103 +++++
 security/keys/key.c                                |   8 +
 security/keys/keyring.c                            |   4 +
 32 files changed, 2478 insertions(+), 215 deletions(-)
 create mode 100644 crypto/asymmetric_keys/mscode.asn1
 create mode 100644 crypto/asymmetric_keys/mscode_parser.c
 create mode 100644 crypto/asymmetric_keys/pefile_parser.c
 create mode 100644 crypto/asymmetric_keys/pefile_parser.h
 create mode 100644 crypto/asymmetric_keys/pkcs7.asn1
 create mode 100644 crypto/asymmetric_keys/pkcs7_parser.c
 create mode 100644 crypto/asymmetric_keys/pkcs7_parser.h
 create mode 100644 crypto/asymmetric_keys/pkcs7_trust.c
 create mode 100644 crypto/asymmetric_keys/pkcs7_verify.c
 create mode 100644 include/keys/system_keyring.h
 create mode 100644 include/linux/pe.h
 delete mode 100644 kernel/modsign_pubkey.c
 rename kernel/{modsign_certificate.S => system_certificates.S} (72%)
 create mode 100644 kernel/system_keyring.c

Re: [GIT PULL] Load keys from signed PE binaries

[Linus Torvalds]

On Thu, Feb 21, 2013 at 7:47 AM, David Howells <dhowells@redhat.com> wrote:
>
> Can you pull this patchset please?

Not without a lot more discussion first.

Quite frankly, this is f*cking moronic. The whole thing seems to be
designed around stupid interfaces, for completely moronic reasons. Why
should we do this?

I already dislike our existing X.509 parser. And this makes the
idiotic complicated interfaces, and now it goes up to 11.

            Linus

Re: [GIT PULL] Load keys from signed PE binaries

[Matthew Garrett]

On Thu, Feb 21, 2013 at 08:39:55AM -0800, Linus Torvalds wrote:
> On Thu, Feb 21, 2013 at 7:47 AM, David Howells <dhowells@redhat.com> wrote:
> >
> > Can you pull this patchset please?
> 
> Not without a lot more discussion first.
> 
> Quite frankly, this is f*cking moronic. The whole thing seems to be
> designed around stupid interfaces, for completely moronic reasons. Why
> should we do this?

There's only one signing authority, and they only sign PE binaries.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [GIT PULL] Load keys from signed PE binaries

[Linus Torvalds]

On Thu, Feb 21, 2013 at 8:42 AM, Matthew Garrett <mjg59@srcf.ucam.org> wrote:
>
> There's only one signing authority, and they only sign PE binaries.

Guys, this is not a dick-sucking contest.

If you want to parse PE binaries, go right ahead.

If Red Hat wants to deep-throat Microsoft, that's *your* issue.  That
has nothing what-so-ever to do with the kernel I maintain. It's
trivial for you guys to have a signing machine that parses the PE
binary, verifies the signatures, and signs the resulting keys with
your own key. You already wrote the code, for chissake, it's in that
f*cking pull request.

Why should *I* care? Why should the kernel care about some idiotic "we
only sign PE binaries" stupidity? We support X.509, which is the
standard for signing.

Do this in user land on a trusted machine. There is zero excuse for
doing it in the kernel.

               Linus

Re: [GIT PULL] Load keys from signed PE binaries

[Matthew Garrett]

On Thu, Feb 21, 2013 at 08:58:45AM -0800, Linus Torvalds wrote:

> If Red Hat wants to deep-throat Microsoft, that's *your* issue.  That
> has nothing what-so-ever to do with the kernel I maintain. It's
> trivial for you guys to have a signing machine that parses the PE
> binary, verifies the signatures, and signs the resulting keys with
> your own key. You already wrote the code, for chissake, it's in that
> f*cking pull request.

There's one significant practical awkwardness, which is that it makes 
key revocation a multi-step process - the blacklisted hash is going to 
be for the PE and not the key itself. I guess the original hash could be 
stuffed in some metadata in the key, but urgh.

Vendors want to ship keys that have been signed by a trusted party. 
Right now the only one that fits the bill is Microsoft, because 
apparently the only thing vendors love more than shitty firmware is 
following Microsoft specs. The equivalent isn't just Red Hat (or anyone 
else) programmatically re-signing those keys, it's re-signing those keys 
with a key that's trusted by the upstream kernel. Would you be willing 
to carry a default trusted key if some sucker/upstanding and 
trustworthy member of society hosted a re-signing service? Or should we 
just assume that anyone who wants to ship external modules is a fucking 
idiot and deserves to be miserable?

(I mean, *I'm* fine with the idea that they're fucking idiots and 
deserve to be miserable, but apparently there's people who think this is 
a vital part of a business model)

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [GIT PULL] Load keys from signed PE binaries

[Linus Torvalds]

On Thu, Feb 21, 2013 at 9:49 AM, Matthew Garrett <mjg59@srcf.ucam.org> wrote:
>
> Vendors want to ship keys that have been signed by a trusted party.
> Right now the only one that fits the bill is Microsoft, because
> apparently the only thing vendors love more than shitty firmware is
> following Microsoft specs.

Quite frankly, I doubt that anybody will ever care, plus getting me to
care about some vendor that ships external binary-only modules is
going to be hard as hell.

Plus quite frankly, signing random kernel vendor modules (indirectly)
with a MS key is f*cking stupid to begin with.

In other words, I really don't see why we should bend over backwards,
when there really is no reason to. It's adding stupid code to the
kernel only to encourage stupidities in other people.

Seriously, if somebody wants to make a binary module for Fedora 18 or
whatever, they should go to Red Hat and ask whether RH is willing to
sign their key. And the whole "no, we only think it makes sense to
trust MS keys" argument is so f*cking stupid that if somebody really
brings that up, I can only throw my hands up and say "whatever".

In other words, none of this makes me think that we should do stupid
things just to perpetuate the stupidity. And I don't believe in the
argument to begin with.

Besides, let's face it, Red Hat is going to sign the official nVidia
and AMD binary modules anyway. Don't even bother to pretend anything
else.

                         Linus

Re: [GIT PULL] Load keys from signed PE binaries

[Matthew Garrett]

On Thu, Feb 21, 2013 at 10:03:20AM -0800, Linus Torvalds wrote:

> Seriously, if somebody wants to make a binary module for Fedora 18 or
> whatever, they should go to Red Hat and ask whether RH is willing to
> sign their key. And the whole "no, we only think it makes sense to
> trust MS keys" argument is so f*cking stupid that if somebody really
> brings that up, I can only throw my hands up and say "whatever".

MS have infrastructure to do identity verification and actually run some 
kind of vaguely responsible CA, and I don't trust Red Hat to be able to 
do that. And if the machine's carrying Microsoft's key in its firmware 
then you *already* trust Microsoft, because if the bad guy can get 
something signed by them then he's already just replaced your bootloader 
instead of pissing about inserting modules. Using the hardware keys as 
the root of trust makes practical sense.

> Besides, let's face it, Red Hat is going to sign the official nVidia
> and AMD binary modules anyway. Don't even bother to pretend anything
> else.

I don't think there's any chance of them signing modules. But it's a 
given that RHEL's going to end up trusting keys owned by nvidia and amd 
somehow, and chances are that's going to be based on the Microsoft 
signing service. The question is whether there's a benefit in ensuring 
that the same key is trusted by RHEL, Ubuntu, Suse and everyone else or 
whether different kernels are going to have completely different 
policies.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [GIT PULL] Load keys from signed PE binaries

[David Howells]

Linus Torvalds <torvalds@linux-foundation.org> wrote:

> > There's only one signing authority, and they only sign PE binaries.
> 
> If Red Hat wants to deep-throat Microsoft, that's *your* issue.  That
> has nothing what-so-ever to do with the kernel I maintain. It's
> trivial for you guys to have a signing machine that parses the PE
> binary, verifies the signatures, and signs the resulting keys with
> your own key. You already wrote the code, for chissake, it's in that
> f*cking pull request.

There's a problem with your idea.

 (1) Microsoft's revocation certificates would be based on the hash of the PE
     binary, not the key.

 (2) Re-signing would make the keys then dependent on our master key rather
     than directly on Microsoft's.  Microsoft's revocation certificates[*]
     would then be useless.

 (3) The only way Microsoft could then revoke the extra keys would be to
     revoke our *master* key.

[*] Assuming of course we add support for these.

David

Re: [GIT PULL] Load keys from signed PE binaries

[Matthew Garrett]

I don't think that's a problem. Just put the original binary hash in the 
certificate before signing it, and extend the X.509 parser to refuse 
certificates that have a tag that's present in dbx.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [GIT PULL] Load keys from signed PE binaries

[Linus Torvalds]

On Thu, Feb 21, 2013 at 10:17 AM, David Howells <dhowells@redhat.com> wrote:
>
> There's a problem with your idea.

You continue to miss the big question:

 - why should the kernel care?

 - why do you bother with the MS keysigning of Linux kernel modules to
begin with?

Your arguments only make sense if you accept those insane assumptions
to begin with. And I don't.

           Linus

Re: [GIT PULL] Load keys from signed PE binaries

[Peter Jones]

On Thu, Feb 21, 2013 at 10:25:47AM -0800, Linus Torvalds wrote:
>  - why do you bother with the MS keysigning of Linux kernel modules to
> begin with?

This is not actually what the patchset implements.  All it's done here
is using PE files as envelopes for keys.  The usage this enables is to
allow for whoever makes a module (binary only or merely out of tree for
whatever reason) to sign it and vouch for it themselves.  That could
include, for example, a systemtap module.

-- 
        Peter

Re: [GIT PULL] Load keys from signed PE binaries

[Linus Torvalds]

On Thu, Feb 21, 2013 at 10:34 AM, Peter Jones <pjones@redhat.com> wrote:
> On Thu, Feb 21, 2013 at 10:25:47AM -0800, Linus Torvalds wrote:
>>  - why do you bother with the MS keysigning of Linux kernel modules to
>> begin with?
>
> This is not actually what the patchset implements.  All it's done here
> is using PE files as envelopes for keys.  The usage this enables is to
> allow for whoever makes a module (binary only or merely out of tree for
> whatever reason) to sign it and vouch for it themselves.  That could
> include, for example, a systemtap module.

Umm. And which part of "We already support that, using standard X.509
certificates" did we suddenly miss?

So no. The PE file thing makes no sense what-so-ever. What you mention
we can already do, and we already do it *better*.

                Linus

Re: [GIT PULL] Load keys from signed PE binaries

[Peter Jones]

On Thu, Feb 21, 2013 at 10:56:44AM -0800, Linus Torvalds wrote:
> On Thu, Feb 21, 2013 at 10:34 AM, Peter Jones <pjones@redhat.com> wrote:
> > On Thu, Feb 21, 2013 at 10:25:47AM -0800, Linus Torvalds wrote:
> >>  - why do you bother with the MS keysigning of Linux kernel modules to
> >> begin with?
> >
> > This is not actually what the patchset implements.  All it's done here
> > is using PE files as envelopes for keys.  The usage this enables is to
> > allow for whoever makes a module (binary only or merely out of tree for
> > whatever reason) to sign it and vouch for it themselves.  That could
> > include, for example, a systemtap module.
> 
> Umm. And which part of "We already support that, using standard X.509
> certificates" did we suddenly miss?
> 
> So no. The PE file thing makes no sense what-so-ever. What you mention
> we can already do, and we already do it *better*.

It's certainly true that we can use x509 signatures to chain trust from
x509 keys to other x509 keys, but when we do, we don't get to use the
hardware as the root of trust with any CA that actually *exists*.

-- 
        Peter

Re: [GIT PULL] Load keys from signed PE binaries

[Matthew Garrett]

On Thu, Feb 21, 2013 at 10:56:44AM -0800, Linus Torvalds wrote:

> So no. The PE file thing makes no sense what-so-ever. What you mention
> we can already do, and we already do it *better*.

We can already do it assuming that someone's willing to run the service 
to bridge between PE and X509, and assuming you're willing to merge 
their public key.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [GIT PULL] Load keys from signed PE binaries

[Theodore Ts'o]

On Thu, Feb 21, 2013 at 06:17:33PM +0000, David Howells wrote:
> 
> There's a problem with your idea.
> 
>  (1) Microsoft's revocation certificates would be based on the hash of the PE
>      binary, not the key.
> 
>  (2) Re-signing would make the keys then dependent on our master key rather
>      than directly on Microsoft's.  Microsoft's revocation certificates[*]
>      would then be useless.
> 
>  (3) The only way Microsoft could then revoke the extra keys would be to
>      revoke our *master* key.

Well, this hypothetical service could also simply scan the Microsoft
revocation certificates (aka CRL's), and if the service detects a PE
hash that it relied upon to resign the module, it could then issue its
own CRL revoking the signature on the module.

If it is run this way, programmatically, I'll note that anyone can run
this service.  It doesn't have to be Red Hat.  It could be Linux
Foundation, if the LF wanted to support this whole code signing
insanity.  (Which I really think is completely overblown, and I'm
going to be amused when this blows to hell all of Red Hat's
investments in Systemtap, but whatever.)  Given that I think this
whole thing is insane, I completely agree with Linus's attempt to keep
this insanity as far away from the upstream kernel as we can.  :-/

     	      	     	       	   - Ted

Re: [GIT PULL] Load keys from signed PE binaries

[Vivek Goyal]

On Thu, Feb 21, 2013 at 10:56:44AM -0800, Linus Torvalds wrote:

[..]
> So no. The PE file thing makes no sense what-so-ever. What you mention
> we can already do, and we already do it *better*.

IIUC, PE/COFF signature verification bits can be useful for verifying
the signature of PE/COFF signed bzImage. This verification will be
required before kexec decides to load the kernel.

Thanks
Vivek

Re: [GIT PULL] Load keys from signed PE binaries

[Matthew Garrett]

On Thu, Feb 21, 2013 at 03:31:19PM -0500, Vivek Goyal wrote:
> On Thu, Feb 21, 2013 at 10:56:44AM -0800, Linus Torvalds wrote:
> 
> [..]
> > So no. The PE file thing makes no sense what-so-ever. What you mention
> > we can already do, and we already do it *better*.
> 
> IIUC, PE/COFF signature verification bits can be useful for verifying
> the signature of PE/COFF signed bzImage. This verification will be
> required before kexec decides to load the kernel.

Only if the kexec validation's being done in kernel. We'd need agreement 
on that before it's a justification.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [GIT PULL] Load keys from signed PE binaries

[Vivek Goyal]

On Thu, Feb 21, 2013 at 08:32:54PM +0000, Matthew Garrett wrote:
> On Thu, Feb 21, 2013 at 03:31:19PM -0500, Vivek Goyal wrote:
> > On Thu, Feb 21, 2013 at 10:56:44AM -0800, Linus Torvalds wrote:
> > 
> > [..]
> > > So no. The PE file thing makes no sense what-so-ever. What you mention
> > > we can already do, and we already do it *better*.
> > 
> > IIUC, PE/COFF signature verification bits can be useful for verifying
> > the signature of PE/COFF signed bzImage. This verification will be
> > required before kexec decides to load the kernel.
> 
> Only if the kexec validation's being done in kernel. We'd need agreement 
> on that before it's a justification.

Even if /sbin/kexec does bzImage validation I think it will require
kernel's help. (This is assuming that only /sbin/kexec is signed and we
can't trust user space crypto libraries).

Thanks
Vivek

Re: [GIT PULL] Load keys from signed PE binaries

[Peter Jones]

On Thu, Feb 21, 2013 at 10:03:20AM -0800, Linus Torvalds wrote:
> Besides, let's face it, Red Hat is going to sign the official nVidia
> and AMD binary modules anyway. Don't even bother to pretend anything
> else.

I just want to make sure this doesn't go unresponded to - Red Hat
will not sign kernel modules built by an outside source. We're simply
not going to sign these kernel modules. That's one of the big reasons
we want a setup where they can sign their own modules in the first place.

-- 
        Peter

Re: [GIT PULL] Load keys from signed PE binaries

[Florian Weimer]

* Matthew Garrett:

> There's only one signing authority, and they only sign PE binaries.

There are at least two, with different policies, albeit run by the
same organization.  Actually, we don't know how many authorities are
out there which have non-localized reach, so it's ... interesting to
attempt to construct any form of security based on that.

But what puzzles me most is why anyone would assume that the UEFI
application signing process somehow ensures that the embedded
certificate is non-malicious.  We cannot even track it back to the
submitter because the third-pary market place UEFI authority only
issues pseudonymous proxy certificates.  This utterly useless for any
purpose whatsoever, with the notable exception of avoding one
additional step when setting up a dual-boot machine (which will not
even work reliably until we switch to overwriting the Windows boot
loader, like in the pre-UEFI days).

Seriously, folks, can we go back one step and discuss what problem you
are trying to solve?  Is it about allowing third-party kernel modules
in an environment which does not allow unsigned ring 0 code execution?

Re: [GIT PULL] Load keys from signed PE binaries

[Florian Weimer]

* Matthew Garrett:

> I don't think that's a problem. Just put the original binary hash in the 
> certificate before signing it, and extend the X.509 parser to refuse 
> certificates that have a tag that's present in dbx.

Why would Microsoft put a hash of something into dbx which they
haven't signed?  Wouldn't this make them subject to a
denial-of-service attack on their platform if they revoke something
with surprising consequences?

Re: [GIT PULL] Load keys from signed PE binaries

[Florian Weimer]

* Peter Jones:

> I just want to make sure this doesn't go unresponded to - Red Hat
> will not sign kernel modules built by an outside source. We're simply
> not going to sign these kernel modules. That's one of the big reasons
> we want a setup where they can sign their own modules in the first place.

You could just drop the requirement that ring 0 code must be signed.
I don't think Windows 8 enforces this, but I'm not yet sure if there
is a physical presence check before you can enter a mode in which
Windows loads self-signed kernel modules.

Re: [GIT PULL] Load keys from signed PE binaries

[Matthew Garrett]

On Mon, Feb 25, 2013 at 03:46:14PM +0100, Florian Weimer wrote:

> You could just drop the requirement that ring 0 code must be signed.
> I don't think Windows 8 enforces this, but I'm not yet sure if there
> is a physical presence check before you can enter a mode in which
> Windows loads self-signed kernel modules.

Windows 8 will not load unsigned drivers if Secure Boot is enabled.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [GIT PULL] Load keys from signed PE binaries

[Matthew Garrett]

On Mon, Feb 25, 2013 at 03:33:12PM +0100, Florian Weimer wrote:
> * Matthew Garrett:
> 
> > I don't think that's a problem. Just put the original binary hash in the 
> > certificate before signing it, and extend the X.509 parser to refuse 
> > certificates that have a tag that's present in dbx.
> 
> Why would Microsoft put a hash of something into dbx which they
> haven't signed?  Wouldn't this make them subject to a
> denial-of-service attack on their platform if they revoke something
> with surprising consequences?

? The entire point is that the key is in a binary that Microsoft have 
signed.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [GIT PULL] Load keys from signed PE binaries

[Matthew Garrett]

On Mon, Feb 25, 2013 at 03:28:32PM +0100, Florian Weimer wrote:

> But what puzzles me most is why anyone would assume that the UEFI
> application signing process somehow ensures that the embedded
> certificate is non-malicious.  We cannot even track it back to the
> submitter because the third-pary market place UEFI authority only
> issues pseudonymous proxy certificates.  This utterly useless for any
> purpose whatsoever, with the notable exception of avoding one
> additional step when setting up a dual-boot machine (which will not
> even work reliably until we switch to overwriting the Windows boot
> loader, like in the pre-UEFI days).

If your firmware trusts objects signed by Microsoft, you have to assume 
that objects signed by Microsoft are trustworthy. There's no way to 
build a security model otherwise. Are Microsoft trustworthy? We don't 
know. If you don't trust Microsoft, remove their key from db.

> Seriously, folks, can we go back one step and discuss what problem you
> are trying to solve?  Is it about allowing third-party kernel modules
> in an environment which does not allow unsigned ring 0 code execution?

The problem I'm trying to solve is "Don't permit Linux to be used as a 
bootloader for backdoored versions of other operating systems". Any 
other security benefit is a happy side effect.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [GIT PULL] Load keys from signed PE binaries

[Florian Weimer]

* Matthew Garrett:

> On Mon, Feb 25, 2013 at 03:46:14PM +0100, Florian Weimer wrote:
>
>> You could just drop the requirement that ring 0 code must be signed.
>> I don't think Windows 8 enforces this, but I'm not yet sure if there
>> is a physical presence check before you can enter a mode in which
>> Windows loads self-signed kernel modules.
>
> Windows 8 will not load unsigned drivers if Secure Boot is enabled.

What about "bcdedit /set ... testsigning on"?

Re: [GIT PULL] Load keys from signed PE binaries

[Matthew Garrett]

On Mon, Feb 25, 2013 at 04:50:50PM +0100, Florian Weimer wrote:
> * Matthew Garrett:
> 
> > On Mon, Feb 25, 2013 at 03:46:14PM +0100, Florian Weimer wrote:
> >
> >> You could just drop the requirement that ring 0 code must be signed.
> >> I don't think Windows 8 enforces this, but I'm not yet sure if there
> >> is a physical presence check before you can enter a mode in which
> >> Windows loads self-signed kernel modules.
> >
> > Windows 8 will not load unsigned drivers if Secure Boot is enabled.
> 
> What about "bcdedit /set ... testsigning on"?

Windows 8 will not load unsigned drivers if Secure Boot is enabled.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [GIT PULL] Load keys from signed PE binaries

[Chris Friesen]

On 02/25/2013 10:14 AM, Matthew Garrett wrote:
> On Mon, Feb 25, 2013 at 04:50:50PM +0100, Florian Weimer wrote:
>> * Matthew Garrett:
>>
>>> On Mon, Feb 25, 2013 at 03:46:14PM +0100, Florian Weimer wrote:
>>>
>>>> You could just drop the requirement that ring 0 code must be signed.
>>>> I don't think Windows 8 enforces this, but I'm not yet sure if there
>>>> is a physical presence check before you can enter a mode in which
>>>> Windows loads self-signed kernel modules.
>>>
>>> Windows 8 will not load unsigned drivers if Secure Boot is enabled.
>>
>> What about "bcdedit /set ... testsigning on"?
>
> Windows 8 will not load unsigned drivers if Secure Boot is enabled.

For reference:

http://msdn.microsoft.com/en-us/library/windows/desktop/hh848062%28v=vs.85%29.aspx

Chris

Re: [GIT PULL] Load keys from signed PE binaries

[David Howells]

Florian Weimer <fw@deneb.enyo.de> wrote:

> Seriously, folks, can we go back one step and discuss what problem you
> are trying to solve?  Is it about allowing third-party kernel modules
> in an environment which does not allow unsigned ring 0 code execution?

Let me try and lay things out:

 (1) Like it or not, the reality is that machines exist that have UEFI secure
     boot.  We want it to be possible for people to be able to install and run
     Linux on these.

 (2) Unless secure boot is completely disabled, the operating system boot
     loader must be signed by a key that's in the UEFI key database.

 (3) We don't want to stop people from being able to dual boot Windows (and
     other OS's - but Windows is the problematic one), therefore we will need
     to be able to operate with secure mode enabled.

 (4) Machines are shipped with a Microsoft root key.  They are not shipped
     with a Microsoft-independent root key from Red Hat or, say, the Linux
     Foundation.

 (5) Unless we get the administrator to add a key prior to Linux installation,
     Linux cannot be booted on a secure UEFI machine - unless the boot loader
     is signed by Microsoft's key.

 (6) To maintain secure boot mode, the kernel must be signed and the boot
     loader must check the signature on it.  The key must be either compiled
     into the bootloader (and thus validated by the bootloader signature) or
     must reside in the UEFI database.

     [*] Note: This step is simplified a bit.

 (7) To maintain secure boot mode, the kernel modules must be signed and the
     kernel must check the signature on them.  The key must be compiled into
     the kernel or the bootloader or must reside in the UEFI database.

At this point, you have the kernel booted in secure boot mode.  Now, there are
several issues we have to deal with going on from here if we want to *stay* in
secure boot mode:

 (A) Unsigned modules.  These may not be loaded in secure boot mode.  At all.

 (B) Systemtap.  We need to be able to debug live kernels.  Red Hat uses
     systemtap a lot for customer support.  However, the private side of the
     key that was used to sign the normal kernel modules gets discarded during
     the build - massively reducing the probability of the key being leaked -
     and so is not available for signing additional modules outside of the
     build.

 (C) Third party modules.  Despite Linus's graphic assertions to the contrary,
     Red Hat has no intention of signing third party modules.

     [*] Note: We realise that it is the right of people to load weird and
     	 terrific stuff into their kernels...  But we don't want to have to
     	 try and deal with the consequences when they do and the sources
     	 aren't easily available.

 (D) kexec.  To be able to replace one kernel with another under secure boot
     means that you have to be able to trust the replacement kernel.
     Therefore that kernel must also be signed by a trusted key known to the
     kernel.

 (E) /dev/mem and similar.  This is not permitted.  Programs should go through
     drivers rather than directly accessing memory mapped devices.

 (F) Direct hardware instruction and DMA.  This must be vetted thoroughly by
     the driver so that this doesn't permit a device to be used to modify a
     running kernel.

 (G) Suspend to disk.  This is not permitted if it's possible to then alter
     the image and resume it.

Now, E-G above are outside the scope of this discussion - however, dealing
with kexec and the loading of modules is pertinent (kexec's boot target can be
dealt with more or less the same as for a module).  So:

 (a) Red Hat will not sign third party modules.

 (b) I don't imagine Linus wants to take patches to make modules PE rather
     than ELF, so direct module signing by Microsoft is out of the question.

 (c) Thus, to load a module signed by a third party requires the third party's
     key be made available to the kernel first.

 (d) Red Hat will not compile third party keys into its kernels - unless those
     keys come via the upstream kernel.

 (e) If Linus patches the upstream kernel to include third party keys, so be
     it.  That's his decision - in that case we will have those keys
     available.  But given Linus's responses, I find that unlikely.

 (f) We must therefore require the administrator to manually add a key using
     the UEFI shell and/or permit keys to be loaded dynamically.  The latter
     option makes it much easier to use with systemtap without having to take
     a machine down (which may be unacceptable or there may be no guarantee of
     reproducing the behaviour after a reboot).

     [*] Note: since the signing keys are done using the in-kernel keyrings
     	 facility, there is a command that's obviously available for adding
     	 them ("keyctl add").

 (g) We cannot simply permit the dynamic addition of just any old key
     otherwise we may as well not bother with signed modules at all.  The
     public key has to be in a container that's signed by a key the kernel
     already possesses and trusts.  The latter key can be one that is compiled
     into the bootloader or the kernel or could be one previously added (if
     multiple chaining is acceptable) or one resident in the UEFI database.

     X.509 certificates are currently the only container that is supported
     upstream.  Red Hat has also used PGP as a container format in the past.

 (h) Red Hat will not sign third party keys.  This would involve us becoming a
     certificate authority, which we'd rather not do as there's a lot of work
     involved in checking that people who want keys are who they say they are.

 (i) Permitting an external key to be chained from the UEFI database means
     that third party keys do not have to chain from Red Hat's key.
     Theoretically, a third party key could then be signed by anyone who owns
     a key in the UEFI database - Microsoft for instance - and still work
     under Linux.

 (j) To the best of my knowledge, Microsoft will only sign PE binaries and
     will not sign X.509 certificates.

So all my patchset does is to permit us to load a key from a signed PE binary
whilst the kernel is running - assuming that PE binary is signed by a key we
have access to and trust.  We don't actually run the binary - we just parse
it.  Sadly the format is a bit weird and involves a PKCS#7 message embedded in
the PE and several steps of digestion, but it's not particularly hard to deal
with.

We also don't want to force people to go through the steps of manually adding
keys to their UEFI.  The steps vary by UEFI firmware implementation - thus
making documentation hard - and there's always the possibility of hitting a
bug and terminally mucking up their key database.

David

[*] Note also, Red Hat wants to support the revocation, blacklist and
    whitelist mechanisms supported by the UEFI database - but that's a side
    issue.

Re: [GIT PULL] Load keys from signed PE binaries

[Greg KH]

On Mon, Feb 25, 2013 at 11:51:05PM +0000, David Howells wrote:
> 
> Florian Weimer <fw@deneb.enyo.de> wrote:
> 
> > Seriously, folks, can we go back one step and discuss what problem you
> > are trying to solve?  Is it about allowing third-party kernel modules
> > in an environment which does not allow unsigned ring 0 code execution?
> 
> Let me try and lay things out:
> 
>  (1) Like it or not, the reality is that machines exist that have UEFI secure
>      boot.  We want it to be possible for people to be able to install and run
>      Linux on these.
> 
>  (2) Unless secure boot is completely disabled, the operating system boot
>      loader must be signed by a key that's in the UEFI key database.
> 
>  (3) We don't want to stop people from being able to dual boot Windows (and
>      other OS's - but Windows is the problematic one), therefore we will need
>      to be able to operate with secure mode enabled.
> 
>  (4) Machines are shipped with a Microsoft root key.  They are not shipped
>      with a Microsoft-independent root key from Red Hat or, say, the Linux
>      Foundation.
> 
>  (5) Unless we get the administrator to add a key prior to Linux installation,
>      Linux cannot be booted on a secure UEFI machine - unless the boot loader
>      is signed by Microsoft's key.
> 
>  (6) To maintain secure boot mode, the kernel must be signed and the boot
>      loader must check the signature on it.  The key must be either compiled
>      into the bootloader (and thus validated by the bootloader signature) or
>      must reside in the UEFI database.
> 
>      [*] Note: This step is simplified a bit.

That's all fine, and now your machine can boot both Linux and Windows
wonderfully.  Distros have shipped code doing this for a short while now
thanks to Matthew's and other developer's effort in writing a UEFI
bootloader / shim that Microsoft has signed.

>  (7) To maintain secure boot mode, the kernel modules must be signed and the
>      kernel must check the signature on them.  The key must be compiled into
>      the kernel or the bootloader or must reside in the UEFI database.

Wait right here.  This is NOT mandated by UEFI, nor by anyone else.  It
might be a nice thing that some people and companies want to implement,
but please don't think that some external entity is requiring that Linux
implement this, that is not true.

> At this point, you have the kernel booted in secure boot mode.  Now, there are
> several issues we have to deal with going on from here if we want to *stay* in
> secure boot mode:

Well, it's all how you define "secure boot mode", isn't it.  This seems
to be some random thing that people are making up as they go along ("We
must sign firmware!")

>  (A) Unsigned modules.  These may not be loaded in secure boot mode.  At all.

Why not?  Who says so?  See, now you really don't have an argument
besides "the policy I am deciding to make up says so," right?

Same for your other "requirements", these are all self-inflicted, no one
that I can determine is mandating any of these, who is deciding that
Linux MUST follow this policy?  I'm not saying that they are not nice
things to have, personally, I want some of these things for my own
machines just to make things more secure, but again, these are "I want
to have", not "Someone else is saying Linux MUST have."

thanks,

greg k-h

Re: [GIT PULL] Load keys from signed PE binaries

[Matthew Garrett]

On Mon, Feb 25, 2013 at 04:59:55PM -0800, Greg KH wrote:

> Wait right here.  This is NOT mandated by UEFI, nor by anyone else.  It
> might be a nice thing that some people and companies want to implement,
> but please don't think that some external entity is requiring that Linux
> implement this, that is not true.

Oh, come on Greg. Allowing unsigned modules allows loading arbitrary 
code into the kernel, and allowing arbitrary code into the kernel means 
that the kernel can be used to directly boot a modified copy of the 
Windows kernel. Avoiding that scenario is *explicitly* mandated by 
Microsoft. We can avoid it by either not using Microsoft as the root of 
trust or by requiring explicit key installation during the OS install 
process, but both of those make OS installation more difficult. If we 
want Linux to Just Work out of the box on Microsoft-certified hardware, 
this is one of the rules we have to live by.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [GIT PULL] Load keys from signed PE binaries

[Greg KH]

On Tue, Feb 26, 2013 at 02:33:32AM +0000, Matthew Garrett wrote:
> On Mon, Feb 25, 2013 at 04:59:55PM -0800, Greg KH wrote:
> 
> > Wait right here.  This is NOT mandated by UEFI, nor by anyone else.  It
> > might be a nice thing that some people and companies want to implement,
> > but please don't think that some external entity is requiring that Linux
> > implement this, that is not true.
> 
> Oh, come on Greg. Allowing unsigned modules allows loading arbitrary 
> code into the kernel, and allowing arbitrary code into the kernel means 
> that the kernel can be used to directly boot a modified copy of the 
> Windows kernel. Avoiding that scenario is *explicitly* mandated by 
> Microsoft.

Then why is the signed shim is currently being used by successfully by
distros that do not use signed kernel modules?

> We can avoid it by either not using Microsoft as the root of 
> trust or by requiring explicit key installation during the OS install 
> process, but both of those make OS installation more difficult. If we 
> want Linux to Just Work out of the box on Microsoft-certified hardware, 
> this is one of the rules we have to live by.

I don't see that being required in the wording for the Microsoft signing
authority, and in personal discussions with them, they say it would be
nice, but they can't force the issue.  Where does it say this in the
agreement specifically?

thanks,

greg k-h

Re: [GIT PULL] Load keys from signed PE binaries

[Matthew Garrett]

On Mon, Feb 25, 2013 at 07:02:49PM -0800, Greg KH wrote:
> On Tue, Feb 26, 2013 at 02:33:32AM +0000, Matthew Garrett wrote:
> > Oh, come on Greg. Allowing unsigned modules allows loading arbitrary 
> > code into the kernel, and allowing arbitrary code into the kernel means 
> > that the kernel can be used to directly boot a modified copy of the 
> > Windows kernel. Avoiding that scenario is *explicitly* mandated by 
> > Microsoft.
> 
> Then why is the signed shim is currently being used by successfully by
> distros that do not use signed kernel modules?

Because Microsoft have indicated that they'd be taking a reactive 
approach to blacklisting and because, so far, nobody has decided to 
write the trivial proof of concept that demonstrates the problem.

> > We can avoid it by either not using Microsoft as the root of 
> > trust or by requiring explicit key installation during the OS install 
> > process, but both of those make OS installation more difficult. If we 
> > want Linux to Just Work out of the box on Microsoft-certified hardware, 
> > this is one of the rules we have to live by.
> 
> I don't see that being required in the wording for the Microsoft signing
> authority, and in personal discussions with them, they say it would be
> nice, but they can't force the issue.  Where does it say this in the
> agreement specifically?

"In addition, in the case of Microsoft’s digital signatures of UEFI 
Code, Microsoft may remove a Compatible Product from the Microsoft 
Compatibility Lists and/or revoke the digital signature upon 30 days’ 
notice to Company in the event Microsoft determines in its sole judgment 
that the security of the UEFI Code is compromised."

The ability to use the signed code to boot an untrusted copy of the 
Windows kernel is a clear breach of the trust model.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [GIT PULL] Load keys from signed PE binaries

[Theodore Ts'o]

On Tue, Feb 26, 2013 at 03:13:38AM +0000, Matthew Garrett wrote:
> 
> Because Microsoft have indicated that they'd be taking a reactive 
> approach to blacklisting and because, so far, nobody has decided to 
> write the trivial proof of concept that demonstrates the problem.

Microsoft would take a severe hit both from a PR perspective, as well
as incurring significant legal risks if they did that in certain
jourisdictions --- in particular, I suspect in Europe, if Microsoft
were to break the ability of Linux distributions from booting, it
would be significantly frowned upon.

So Microsoft may have privately threatened this to certain Red Hat
attendees (threats are cheap, but it's not obvious that they would
necessarily follow through on this threat.

						- Ted

Re: [GIT PULL] Load keys from signed PE binaries

[Matthew Garrett]

On Mon, Feb 25, 2013 at 10:25:08PM -0500, Theodore Ts'o wrote:
> On Tue, Feb 26, 2013 at 03:13:38AM +0000, Matthew Garrett wrote:
> > 
> > Because Microsoft have indicated that they'd be taking a reactive 
> > approach to blacklisting and because, so far, nobody has decided to 
> > write the trivial proof of concept that demonstrates the problem.
> 
> Microsoft would take a severe hit both from a PR perspective, as well
> as incurring significant legal risks if they did that in certain
> jourisdictions --- in particular, I suspect in Europe, if Microsoft
> were to break the ability of Linux distributions from booting, it
> would be significantly frowned upon.

If a Linux vendor chose to knowingly breach the obligations they agreed 
to, you don't think there'd be any PR hit?

> So Microsoft may have privately threatened this to certain Red Hat
> attendees (threats are cheap, but it's not obvious that they would
> necessarily follow through on this threat.

You're happy advising Linux vendors that they don't need to worry about 
module signing because it's "not obvious" that Microsoft would actually 
enforce the security model they've spent significant money developing 
and advertising?

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [GIT PULL] Load keys from signed PE binaries

[Greg KH]

On Tue, Feb 26, 2013 at 03:13:38AM +0000, Matthew Garrett wrote:
> On Mon, Feb 25, 2013 at 07:02:49PM -0800, Greg KH wrote:
> > On Tue, Feb 26, 2013 at 02:33:32AM +0000, Matthew Garrett wrote:
> > > Oh, come on Greg. Allowing unsigned modules allows loading arbitrary 
> > > code into the kernel, and allowing arbitrary code into the kernel means 
> > > that the kernel can be used to directly boot a modified copy of the 
> > > Windows kernel. Avoiding that scenario is *explicitly* mandated by 
> > > Microsoft.
> > 
> > Then why is the signed shim is currently being used by successfully by
> > distros that do not use signed kernel modules?
> 
> Because Microsoft have indicated that they'd be taking a reactive 
> approach to blacklisting and because, so far, nobody has decided to 
> write the trivial proof of concept that demonstrates the problem.

So, once that proof is written, suddenly all of the working Linux
distros's keys will be revoked?  That will be fun to watch happen, and
odds are, it will not.  Imagine the PR fun that will cause :)

> > > We can avoid it by either not using Microsoft as the root of 
> > > trust or by requiring explicit key installation during the OS install 
> > > process, but both of those make OS installation more difficult. If we 
> > > want Linux to Just Work out of the box on Microsoft-certified hardware, 
> > > this is one of the rules we have to live by.
> > 
> > I don't see that being required in the wording for the Microsoft signing
> > authority, and in personal discussions with them, they say it would be
> > nice, but they can't force the issue.  Where does it say this in the
> > agreement specifically?
> 
> "In addition, in the case of Microsoft’s digital signatures of UEFI 
> Code, Microsoft may remove a Compatible Product from the Microsoft 
> Compatibility Lists and/or revoke the digital signature upon 30 days’ 
> notice to Company in the event Microsoft determines in its sole judgment 
> that the security of the UEFI Code is compromised."
> 
> The ability to use the signed code to boot an untrusted copy of the 
> Windows kernel is a clear breach of the trust model.

I don't buy it.  Yes, I understand this is your position, and has been
all along, and _maybe_ you can extend it to "we should sign our kernel
modules", but to take it farther than that, like the list David has
described, is not required by anyone here.

Yes, they are all "nice" things to have, but I fail to see how Microsoft
should be dictating how Linux, or any other operating system, works,
especially when they aren't even signing the kernel, they are merely
signing a bootloader shim and saying "do your best for keeping the rest
of the system secure please."

thanks,

greg k-h

Re: [GIT PULL] Load keys from signed PE binaries

[Linus Torvalds]

On Mon, Feb 25, 2013 at 7:28 PM, Matthew Garrett <mjg59@srcf.ucam.org> wrote:
>
> You're happy advising Linux vendors that they don't need to worry about
> module signing because it's "not obvious" that Microsoft would actually
> enforce the security model they've spent significant money developing
> and advertising?

And you're happy shilling for a broken model?

The fact is, the only valid user for the whole security model is to
PROTECT THE USER.

Your arguments constantly seem to miss that rather big point. You
think this is about bending over when MS whispers sweet nothings in
your ear..

The whole and only reason I ever merged module signatures is because
it actually allows *users* to do a good job at security. You, on the
other hand, seem to have drunk the cool-aid on the whole "let's
control the user" crap.

Did you forget what security was all about?

              Linus

Re: [GIT PULL] Load keys from signed PE binaries

[Matthew Garrett]

On Mon, Feb 25, 2013 at 07:31:56PM -0800, Greg KH wrote:
> On Tue, Feb 26, 2013 at 03:13:38AM +0000, Matthew Garrett wrote:
> > Because Microsoft have indicated that they'd be taking a reactive 
> > approach to blacklisting and because, so far, nobody has decided to 
> > write the trivial proof of concept that demonstrates the problem.
> 
> So, once that proof is written, suddenly all of the working Linux
> distros's keys will be revoked?  That will be fun to watch happen, and
> odds are, it will not.  Imagine the PR fun that will cause :)

No. Why would they be?

> > "In addition, in the case of Microsoft’s digital signatures of UEFI 
> > Code, Microsoft may remove a Compatible Product from the Microsoft 
> > Compatibility Lists and/or revoke the digital signature upon 30 days’ 
> > notice to Company in the event Microsoft determines in its sole judgment 
> > that the security of the UEFI Code is compromised."
> > 
> > The ability to use the signed code to boot an untrusted copy of the 
> > Windows kernel is a clear breach of the trust model.
> 
> I don't buy it.  Yes, I understand this is your position, and has been
> all along, and _maybe_ you can extend it to "we should sign our kernel
> modules", but to take it farther than that, like the list David has
> described, is not required by anyone here.

Failing to take it to that extent is dangerously naive. If you can do it 
with kernel modules, you can do it with kexec. If you can do it with 
kexec, you can do it with arbitrary mmio access to PCI devices.

> Yes, they are all "nice" things to have, but I fail to see how Microsoft
> should be dictating how Linux, or any other operating system, works,
> especially when they aren't even signing the kernel, they are merely
> signing a bootloader shim and saying "do your best for keeping the rest
> of the system secure please."

Microsoft aren't dictating anything here. We're free not to use their 
signatures. However, if we do use their signatures, we agree to play by 
their rules. Nobody seems to have come up with a viable alternative, so 
here we are.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [GIT PULL] Load keys from signed PE binaries

[Greg KH]

On Tue, Feb 26, 2013 at 03:28:39AM +0000, Matthew Garrett wrote:
> On Mon, Feb 25, 2013 at 10:25:08PM -0500, Theodore Ts'o wrote:
> > On Tue, Feb 26, 2013 at 03:13:38AM +0000, Matthew Garrett wrote:
> > > 
> > > Because Microsoft have indicated that they'd be taking a reactive 
> > > approach to blacklisting and because, so far, nobody has decided to 
> > > write the trivial proof of concept that demonstrates the problem.
> > 
> > Microsoft would take a severe hit both from a PR perspective, as well
> > as incurring significant legal risks if they did that in certain
> > jourisdictions --- in particular, I suspect in Europe, if Microsoft
> > were to break the ability of Linux distributions from booting, it
> > would be significantly frowned upon.
> 
> If a Linux vendor chose to knowingly breach the obligations they agreed 
> to, you don't think there'd be any PR hit?

What "vendor" is there in this case?  You released a signed shim, as did
the Linux Foundation, and lots of distros are now using it, and there
are absolutly no "orginization" behind a bunch of them.  Will your
signed shim be revoked because a random PoC was posted somewhere that
could be used with any kernel booted using it?

thanks,

greg k-h

Re: [GIT PULL] Load keys from signed PE binaries

[Matthew Garrett]

On Mon, Feb 25, 2013 at 07:32:04PM -0800, Linus Torvalds wrote:
> On Mon, Feb 25, 2013 at 7:28 PM, Matthew Garrett <mjg59@srcf.ucam.org> wrote:
> >
> > You're happy advising Linux vendors that they don't need to worry about
> > module signing because it's "not obvious" that Microsoft would actually
> > enforce the security model they've spent significant money developing
> > and advertising?
> 
> And you're happy shilling for a broken model?
>
> The fact is, the only valid user for the whole security model is to
> PROTECT THE USER.

The user Microsoft care about isn't running Linux. The user is running 
Windows, and someone's merely using Linux as a vector to launch their 
backdoored Windows kernel. How do Microsoft protect that user? They 
blacklist the signature used by that Linux bootloader. If we want to 
protect the user's ability to boot Linux, we need to protect the 
Windows users from having Linux used against them.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [GIT PULL] Load keys from signed PE binaries

[Linus Torvalds]

On Mon, Feb 25, 2013 at 7:42 PM, Matthew Garrett <mjg59@srcf.ucam.org> wrote:
>
> The user Microsoft care about isn't running Linux

How f*cking hard is it for you to understand?

Stop arguing about what MS wants. We do not care. We care bout the
*user*. You are continually missing the whole point of security, and
then you make some idiotic arguments about what MS wants you to do.

It's irrelevant. The only thing that matters is what our *users* want
us to do, and protecting *their* rights. As long as you seem to treat
this as some kind of "let's please MS, not our users" issue, all your
arguments are going to be crap.

                Linus

Re: [GIT PULL] Load keys from signed PE binaries

[Matthew Garrett]

On Mon, Feb 25, 2013 at 07:40:31PM -0800, Greg KH wrote:

> What "vendor" is there in this case?  You released a signed shim, as did
> the Linux Foundation, and lots of distros are now using it, and there
> are absolutly no "orginization" behind a bunch of them.  Will your
> signed shim be revoked because a random PoC was posted somewhere that
> could be used with any kernel booted using it?

No, because the version I released doesn't allow you to boot stuff 
without there having been explicit end-user authorisation in advance. 
The LF loader is in the same situation. But no user-focused distribution 
is going to do that.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [GIT PULL] Load keys from signed PE binaries

[Matthew Garrett]

On Mon, Feb 25, 2013 at 07:45:24PM -0800, Linus Torvalds wrote:
> On Mon, Feb 25, 2013 at 7:42 PM, Matthew Garrett <mjg59@srcf.ucam.org> wrote:
> >
> > The user Microsoft care about isn't running Linux
> 
> How f*cking hard is it for you to understand?
> 
> Stop arguing about what MS wants. We do not care. We care bout the
> *user*. You are continually missing the whole point of security, and
> then you make some idiotic arguments about what MS wants you to do.
> 
> It's irrelevant. The only thing that matters is what our *users* want
> us to do, and protecting *their* rights. As long as you seem to treat
> this as some kind of "let's please MS, not our users" issue, all your
> arguments are going to be crap.

Our users want to be able to boot Linux. If Microsoft blacklist a 
distribution's bootloader, that user isn't going to be able to boot 
Linux any more. How does that benefit our users? The user that wants to 
explicitly disable the security is free to do so ("mokutil 
--disable-validation" as root, follow the prompts, reboot), but if 
we only care about *our* users then Microsoft will gleefully blacklist 
us into complete irrelevance.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [GIT PULL] Load keys from signed PE binaries

[Theodore Ts'o]

On Tue, Feb 26, 2013 at 03:28:39AM +0000, Matthew Garrett wrote:
> You're happy advising Linux vendors that they don't need to worry about 
> module signing because it's "not obvious" that Microsoft would actually 
> enforce the security model they've spent significant money developing 
> and advertising?

My advice was to Linus and those who are willing to listen to me, not
to Red Hat.  Red Hat has not generally been receptive to my advice in
the past; not that they have any obligation to listen to me, of
course.  After all, I'm not on Red Hat's payroll.  :-)

Speaking more generally, though, (a) revoking the Linux's key is not
zero-cost to Microsoft, (b) it's also not an instant death sentence to
Linux distributions.  Users can always either disable secure boot
mode, or they can install another signing key.  Yes, that is not the
best user experience, but it's something which is doable.

The other thing to consider is that it's not clear in the long run how
much of a lock Microsoft and Windows 8 will have hardware
manufacturers.  There's already been people discussing how to install
Linux on the Chromebook Pixel.  Other traditional PC manufacturers,
including HP and Lenovo, have started creating non-Windows-8 x86
systems using ChromeOS, which can easily have a stock Linux distro
installed on it, and they come at a variety of different price points.
(Heck, the recent ChromeOS boxes, such as Pixel, come with an open
source BIOS which you can reflash.)

Finally note that secure boot is not an issue on server platforms,
which is where most of the traditional Linux vendors have made their
money.  And those who are making money with pre-installed Linux
systems (i.e., like Ubuntu, or Google with ChromeOS) for consumers are
generally doing so in cooperation with hardware OEM partners, where
there's no reason to kowtow to Microsoft's policies.  So there really
isn't a good reason for Linux vendors to cower in fear of Microsoft.

Much of Microsoft power comes from people letting them have power over
them.  You don't have to do it.  Sometimes it's better to let them
carry through on their threat, and while it will be inconvenient, it
is highly likely they will also take damage from their taking action.
Consider what happened the last time the Republicans carried through
on their threat to shut down the US Federal Government.  Sometimes
it's better to let the blackmailers carry through on their threat, and
then steps from there.  Cowering in fear and paying Danegled rarely
gets rid of the Dane.

Regards,

						- Ted

Re: [GIT PULL] Load keys from signed PE binaries

[Greg KH]

On Tue, Feb 26, 2013 at 03:38:04AM +0000, Matthew Garrett wrote:
> On Mon, Feb 25, 2013 at 07:31:56PM -0800, Greg KH wrote:
> > On Tue, Feb 26, 2013 at 03:13:38AM +0000, Matthew Garrett wrote:
> > > Because Microsoft have indicated that they'd be taking a reactive 
> > > approach to blacklisting and because, so far, nobody has decided to 
> > > write the trivial proof of concept that demonstrates the problem.
> > 
> > So, once that proof is written, suddenly all of the working Linux
> > distros's keys will be revoked?  That will be fun to watch happen, and
> > odds are, it will not.  Imagine the PR fun that will cause :)
> 
> No. Why would they be?

Because they are using the "public" shim that you provided them, or the
Linux Foundation's shim.  Almost no distro, other than the "main" 3-4
will end up getting their own shim signed, the rest will just use the
one you so helpfully provided them :)

> > > "In addition, in the case of Microsoft’s digital signatures of UEFI 
> > > Code, Microsoft may remove a Compatible Product from the Microsoft 
> > > Compatibility Lists and/or revoke the digital signature upon 30 days’ 
> > > notice to Company in the event Microsoft determines in its sole judgment 
> > > that the security of the UEFI Code is compromised."
> > > 
> > > The ability to use the signed code to boot an untrusted copy of the 
> > > Windows kernel is a clear breach of the trust model.
> > 
> > I don't buy it.  Yes, I understand this is your position, and has been
> > all along, and _maybe_ you can extend it to "we should sign our kernel
> > modules", but to take it farther than that, like the list David has
> > described, is not required by anyone here.
> 
> Failing to take it to that extent is dangerously naive. If you can do it 
> with kernel modules, you can do it with kexec. If you can do it with 
> kexec, you can do it with arbitrary mmio access to PCI devices.

Yes you can.  There are all sorts of fun ways you can do this, I can
think of a few more at the moment as well.  So, where does it stop?
And why stop it at all?  Why not just forbid root users at all?

> > Yes, they are all "nice" things to have, but I fail to see how Microsoft
> > should be dictating how Linux, or any other operating system, works,
> > especially when they aren't even signing the kernel, they are merely
> > signing a bootloader shim and saying "do your best for keeping the rest
> > of the system secure please."
> 
> Microsoft aren't dictating anything here. We're free not to use their 
> signatures. However, if we do use their signatures, we agree to play by 
> their rules. Nobody seems to have come up with a viable alternative, so 
> here we are.

Ok, I keep hearing people say, "why doesn't someone else create a
signing authority!" all the time.  And it comes down to one big thing,
money.

The money required to put up a bond to allow a root key to be placed
into the BIOS for just one major OEM is larger than pretty much all of
the Linux companies combined at this moment in time.

The money required to staff up, and put into place the proper
infrastructure to be a signing authority is, I'm pretty sure, larger
than the operating budget of the Linux Foundation at this point in time.
And again, remember the bond requirement of the OEMs.

So that's why the LF, or anyone else, including the UEFI group
themselves, are NOT getting into the key signing business.  Money.

Oh, and the fact that it's just not worth it in the end, but that's a
different topic :)

thanks,

greg k-h

Re: [GIT PULL] Load keys from signed PE binaries

[Matthew Garrett]

On Mon, Feb 25, 2013 at 07:54:16PM -0800, Greg KH wrote:
> On Tue, Feb 26, 2013 at 03:38:04AM +0000, Matthew Garrett wrote:
> > On Mon, Feb 25, 2013 at 07:31:56PM -0800, Greg KH wrote:
> > > So, once that proof is written, suddenly all of the working Linux
> > > distros's keys will be revoked?  That will be fun to watch happen, and
> > > odds are, it will not.  Imagine the PR fun that will cause :)
> > 
> > No. Why would they be?
> 
> Because they are using the "public" shim that you provided them, or the
> Linux Foundation's shim.  Almost no distro, other than the "main" 3-4
> will end up getting their own shim signed, the rest will just use the
> one you so helpfully provided them :)

There's no reason for the LF or generic shim to be blacklisted, since 
neither will load anything without manual intervention. But that also 
means that anyone trying to boot them has to have some knowledge of 
English, and that there's no way to netboot them. But sure, anyone 
planning that approach has much less to worry about.

> > > I don't buy it.  Yes, I understand this is your position, and has been
> > > all along, and _maybe_ you can extend it to "we should sign our kernel
> > > modules", but to take it farther than that, like the list David has
> > > described, is not required by anyone here.
> > 
> > Failing to take it to that extent is dangerously naive. If you can do it 
> > with kernel modules, you can do it with kexec. If you can do it with 
> > kexec, you can do it with arbitrary mmio access to PCI devices.
> 
> Yes you can.  There are all sorts of fun ways you can do this, I can
> think of a few more at the moment as well.  So, where does it stop?
> And why stop it at all?  Why not just forbid root users at all?

Because there's a distinction between ring 0 and ring 3?

> > Microsoft aren't dictating anything here. We're free not to use their 
> > signatures. However, if we do use their signatures, we agree to play by 
> > their rules. Nobody seems to have come up with a viable alternative, so 
> > here we are.
> 
> Ok, I keep hearing people say, "why doesn't someone else create a
> signing authority!" all the time.  And it comes down to one big thing,
> money.

Right. We've failed at creating an alternative. That doesn't mean that 
we get to skip the responsibilities associated with the choice we've 
made.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [GIT PULL] Load keys from signed PE binaries

[Greg KH]

On Tue, Feb 26, 2013 at 04:04:56AM +0000, Matthew Garrett wrote:
> On Mon, Feb 25, 2013 at 07:54:16PM -0800, Greg KH wrote:
> > On Tue, Feb 26, 2013 at 03:38:04AM +0000, Matthew Garrett wrote:
> > > On Mon, Feb 25, 2013 at 07:31:56PM -0800, Greg KH wrote:
> > > > So, once that proof is written, suddenly all of the working Linux
> > > > distros's keys will be revoked?  That will be fun to watch happen, and
> > > > odds are, it will not.  Imagine the PR fun that will cause :)
> > > 
> > > No. Why would they be?
> > 
> > Because they are using the "public" shim that you provided them, or the
> > Linux Foundation's shim.  Almost no distro, other than the "main" 3-4
> > will end up getting their own shim signed, the rest will just use the
> > one you so helpfully provided them :)
> 
> There's no reason for the LF or generic shim to be blacklisted, since 
> neither will load anything without manual intervention. But that also 
> means that anyone trying to boot them has to have some knowledge of 
> English, and that there's no way to netboot them. But sure, anyone 
> planning that approach has much less to worry about.

I don't see anything about "manual intervention" in the wording that you
provided from Microsoft absolving you from the "duty" you feel you owe
them.  I understand you are worried about "automated" exploits, but that
really is just a semantic overall, as we know it is easy to get people
to hit a key when booting just to get on with the process.

> > Yes you can.  There are all sorts of fun ways you can do this, I can
> > think of a few more at the moment as well.  So, where does it stop?
> > And why stop it at all?  Why not just forbid root users at all?
> 
> Because there's a distinction between ring 0 and ring 3?

Since when did you start trusting ring 0 code?  Bozos like me write this
stuff, surely it isn't secure :)

> > > Microsoft aren't dictating anything here. We're free not to use their 
> > > signatures. However, if we do use their signatures, we agree to play by 
> > > their rules. Nobody seems to have come up with a viable alternative, so 
> > > here we are.
> > 
> > Ok, I keep hearing people say, "why doesn't someone else create a
> > signing authority!" all the time.  And it comes down to one big thing,
> > money.
> 
> Right. We've failed at creating an alternative. That doesn't mean that 
> we get to skip the responsibilities associated with the choice we've 
> made.

Wait, who is "we" here?  The community?  The community over-all didn't
agree with anything with Microsoft, that is between the people getting a
signed key and Microsoft.  Again, you are trying to push your (prior)
company's agreement between them and Microsoft onto the community, and
now the community is pushing back, is that a surprise?

thanks,

greg k-h

Re: [GIT PULL] Load keys from signed PE binaries

[Matthew Garrett]

On Mon, Feb 25, 2013 at 08:13:24PM -0800, Greg KH wrote:
> On Tue, Feb 26, 2013 at 04:04:56AM +0000, Matthew Garrett wrote:
> > There's no reason for the LF or generic shim to be blacklisted, since 
> > neither will load anything without manual intervention. But that also 
> > means that anyone trying to boot them has to have some knowledge of 
> > English, and that there's no way to netboot them. But sure, anyone 
> > planning that approach has much less to worry about.
> 
> I don't see anything about "manual intervention" in the wording that you
> provided from Microsoft absolving you from the "duty" you feel you owe
> them.  I understand you are worried about "automated" exploits, but that
> really is just a semantic overall, as we know it is easy to get people
> to hit a key when booting just to get on with the process.

If the user has explicitly enrolled a hash then they're stepping outside 
the trust model. That's why the LF loader shows dire warnings, and why 
shim has deliberately awkward UI. Perhaps we'll have made an incorrect 
judgement and it'll turn out that users can still be manipulated into 
being exploited this way, and in that case we'll have to reappraise some 
of those choices. But given that the barrier there is similar to the 
barrier involved in just telling users to disable Secure Boot entirely, 
I don't think it's terribly likely.

> > > Yes you can.  There are all sorts of fun ways you can do this, I can
> > > think of a few more at the moment as well.  So, where does it stop?
> > > And why stop it at all?  Why not just forbid root users at all?
> > 
> > Because there's a distinction between ring 0 and ring 3?
> 
> Since when did you start trusting ring 0 code?  Bozos like me write this
> stuff, surely it isn't secure :)

The fact that we bother with CVEs seems to suggest that we at least 
aspire to it...

> > Right. We've failed at creating an alternative. That doesn't mean that 
> > we get to skip the responsibilities associated with the choice we've 
> > made.
> 
> Wait, who is "we" here?  The community?  The community over-all didn't
> agree with anything with Microsoft, that is between the people getting a
> signed key and Microsoft.  Again, you are trying to push your (prior)
> company's agreement between them and Microsoft onto the community, and
> now the community is pushing back, is that a surprise?

The community's not obliged to take the patches, and I'm sure Red Hat 
and any other vendors who care can carry them themselves. But it'd be 
nice to avoid even more divergence between upstream and the 
distributions, wouldn't it?

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [GIT PULL] Load keys from signed PE binaries

[Dave Airlie]

>>
>> Right. We've failed at creating an alternative. That doesn't mean that
>> we get to skip the responsibilities associated with the choice we've
>> made.
>
> Wait, who is "we" here?  The community?  The community over-all didn't
> agree with anything with Microsoft, that is between the people getting a
> signed key and Microsoft.  Again, you are trying to push your (prior)
> company's agreement between them and Microsoft onto the community, and
> now the community is pushing back, is that a surprise?

Do you not work for the LF?, Matthew doesn't work for RH, so please
leave the petty my employer said this, and he's better than your
employer and try and stick to technical details.

Maybe the LF can do something useful and get MS to sign an agreement
saying we don't require any of this extra security stuff and that if
Linux is used to root Windows Secureboot platforms, they won't revoke
the key for our bootloaders. Until then you aren't providing anything
more technical than FUD.

Its a simple argument, MS can revoke our keys for whatever reason,
reducing the surface area of reasons for them to do so seems like a
good idea. Unless someone can read the mind of the MS guy that
arbitrarily decides this in 5 years time, or has some sort of signed
agreement, I tend towards protecting the users from having their Linux
not work anymore, because we were scared of a PE loader in the kernel.

Dave.

Re: [GIT PULL] Load keys from signed PE binaries

[Linus Torvalds]

On Mon, Feb 25, 2013 at 7:48 PM, Matthew Garrett <mjg59@srcf.ucam.org> wrote:
>
> Our users want to be able to boot Linux. If Microsoft blacklist a
> distribution's bootloader, that user isn't going to be able to boot
> Linux any more. How does that benefit our users?

How does bringing up an unlikely and bogus scenario - and when people
call you on it, just double down on it - help users?

Stop the fear mongering already.

So here's what I would suggest, and it is based on REAL SECURITY and
on PUTTING THE USER FIRST instead of your continual "let's please
microsoft by doing idiotic crap" approach.

So instead of pleasing microsoft, try to see how we can add real security:

 - a distro should sign its own modules AND NOTHING ELSE by default.
And it damn well shouldn't allow any other modules to be loaded at all
by default, because why the f*ck should it? And what the hell should a
microsoft signature have to do with *anything*?

 - before loading any third-party module, you'd better make sure you
ask the user for permission. On the console. Not using keys. Nothing
like that. Keys will be compromised. Try to limit the damage, but more
importantly, let the user be in control.

 - encourage things like per-host random keys - with the stupid UEFI
checks disabled entirely if required. They are almost certainly going
to be *more* secure than depending on some crazy root of trust based
on a big company, with key signing authorities that trust anybody with
a credit card. Try to teach people about things like that instead.
Encourage people to do their own (random) keys, and adding those to
their UEFI setups (or not: the whole UEFI thing is more about control
than security), and strive to do things like one-time signing with the
private key thrown out entirely. IOW try to encourage *that* kind of
"we made sure to ask the user very explicitly with big warnings and
create his own key for that particular module" security. Real
security, not "we control the user" security.

Sure, users will screw that up too. They'll want to load crazy nvidia
binary modules etc crap. But make it *their* decision, and under
*their* control, instead of trying to tell the world about how this
should be blessed by Microsoft.

Because it really shouldn't be about MS blessings, it should be about
the *user* blessing kernel modules.

Quite frankly, *you* are what he key-hating crazies were afraid of.
You peddle the "control, not security" crap-ware. The whole "MS owns
your machine" is *exactly* the wrong way to use keys.

                 Linus

Re: [GIT PULL] Load keys from signed PE binaries

[Linus Torvalds]

On Mon, Feb 25, 2013 at 8:23 PM, Matthew Garrett <mjg59@srcf.ucam.org> wrote:
>
> If the user has explicitly enrolled a hash then they're stepping outside
> the trust model.

This is the kind of totally bogus crap that no sane person should ever
spout. Stop it.

If the user has explicitly enrolled a hash, then that should be the
*primary* trust model, dammit. That should be very much what you
should care about first and foremost, and that should be your goal in
life. That's when the user says "I'm in control of my own machine, and
I want to trust *this*".

It's not about "stepping outside of the trust model". Quite the
reverse. It's about actually being *part* of the trust model, and
taking control of your own machine. It's the *good* scenario. It's
what you should encourage users to do.

No, it likely can't be the default because we shouldn't expect users
to care enough, but on the other hand the default should definitely
*not* be "enable random third party modules signed indirectly by MS",
which is what your crazy world-view seems to be.

So the first order should be: "we provide modules to cover all normal
users". You use the RH key for that.

The *second* order should be: "we encourage and tell people how to add
their own keys and sign modules they trust".

The third order should probably be "we encourage people to use random
one-time keys - probably with UEFI key checking turned off entirely,
because let's face it, that doesn't really add any real security for
most people". It's what kernel developers and most servers would
probably want to use. They likely don't do the whole UEFI crap anyway,
and random one-time keys are actually better against things like
rootkits etc than *any* centrally administered chain of trust.

Only somewhere really really deep down should the "ok, what about a MS
signature" thing be. It could be part of the user-level application
(part of your distribution) that displays the "are you really sure you
want to load this module with an unrecognized signature? I can tell
that it has a MS signature on it". But by the time you get this far,
you've already failed the first few normal levels.

            Linus

Re: [GIT PULL] Load keys from signed PE binaries

[Theodore Ts'o]

On Tue, Feb 26, 2013 at 02:25:55PM +1000, Dave Airlie wrote:
> 
> Its a simple argument, MS can revoke our keys for whatever reason,
> reducing the surface area of reasons for them to do so seems like a
> good idea. Unless someone can read the mind of the MS guy that
> arbitrarily decides this in 5 years time, or has some sort of signed
> agreement, I tend towards protecting the users from having their Linux
> not work anymore, because we were scared of a PE loader in the kernel.

If Microsoft will revoke keys for whatever reason they want, without
any regard to the potential PR and legal consequences to Microsoft,
there's absolutely **nothing** you can do, short of choosing to use
more open hardware (for example, like the Chromebook Pixel).

If you're that terrified of the completely arbitrary and capricious
Microsoft guy having us by the short hairs, why aid and abet Microsoft
control-freak model?

						- Ted

Re: [GIT PULL] Load keys from signed PE binaries

[Greg KH]

On Tue, Feb 26, 2013 at 02:25:55PM +1000, Dave Airlie wrote:
> >>
> >> Right. We've failed at creating an alternative. That doesn't mean that
> >> we get to skip the responsibilities associated with the choice we've
> >> made.
> >
> > Wait, who is "we" here?  The community?  The community over-all didn't
> > agree with anything with Microsoft, that is between the people getting a
> > signed key and Microsoft.  Again, you are trying to push your (prior)
> > company's agreement between them and Microsoft onto the community, and
> > now the community is pushing back, is that a surprise?
> 
> Do you not work for the LF?, Matthew doesn't work for RH, so please
> leave the petty my employer said this, and he's better than your
> employer and try and stick to technical details.

No, sorry, I'm not trying to say that at all (and my LF employment
agreement is quite weird, I don't speak for them at all, and they can't
tell me what to do, and everyone is happy.)

I am trying to say that the "we" here is NOT the community.  The
community does not have any "responsibility" to Microsoft or any
corporate.  Our only responsibility is to our users, as Linus stated.

thanks,

greg k-h

Re: [GIT PULL] Load keys from signed PE binaries

[Dave Airlie]

On Tue, Feb 26, 2013 at 2:45 PM, Theodore Ts'o <tytso@mit.edu> wrote:
> On Tue, Feb 26, 2013 at 02:25:55PM +1000, Dave Airlie wrote:
>>
>> Its a simple argument, MS can revoke our keys for whatever reason,
>> reducing the surface area of reasons for them to do so seems like a
>> good idea. Unless someone can read the mind of the MS guy that
>> arbitrarily decides this in 5 years time, or has some sort of signed
>> agreement, I tend towards protecting the users from having their Linux
>> not work anymore, because we were scared of a PE loader in the kernel.
>
> If Microsoft will revoke keys for whatever reason they want, without
> any regard to the potential PR and legal consequences to Microsoft,
> there's absolutely **nothing** you can do, short of choosing to use
> more open hardware (for example, like the Chromebook Pixel).
>
> If you're that terrified of the completely arbitrary and capricious
> Microsoft guy having us by the short hairs, why aid and abet Microsoft
> control-freak model?
>

No what I said if you read it, was nobody knows, you don't, Greg
doesn't, Matthew doesn't.

That's the problem you are all arguing like you know shit that none of you know.

So you all have opinions on what Microsoft would do if faced with the
compromise Matthew reports, and really if you think MS are going to
leave a secureboot bypass via Linux live, then you wonder why they are
expending all this money on secureboot at all, since the first person
to write a Linux based exploit is safe because of a PR backlash? At
this point we'd be best served by writing the PoC exploit I suppose
and then seeing what MS do up front!

So it would be nice if LF could undertake to go and talk to Microsoft,
and get vague opinions turned into something real.

Ted you might be at liberty to get a chromebook pixel from google, but
that isn't going to help the other X% of users who have a PC they want
to use Linux on, and maybe boot Windows to do their taxes.

Dave.

Re: [GIT PULL] Load keys from signed PE binaries

[Matthew Garrett]

On Mon, Feb 25, 2013 at 08:31:08PM -0800, Linus Torvalds wrote:
> On Mon, Feb 25, 2013 at 7:48 PM, Matthew Garrett <mjg59@srcf.ucam.org> wrote:
> >
> > Our users want to be able to boot Linux. If Microsoft blacklist a
> > distribution's bootloader, that user isn't going to be able to boot
> > Linux any more. How does that benefit our users?
> 
> How does bringing up an unlikely and bogus scenario - and when people
> call you on it, just double down on it - help users?

What's unlikely or bogus about it? There's incentive to breach the 
Secure Boot trust model, and to do that you need signed code that'll run 
unsigned code in ring 0. Why would the black hats bother finding more 
subtle exploits if they can just write a new kexec loader?

>  - a distro should sign its own modules AND NOTHING ELSE by default.
> And it damn well shouldn't allow any other modules to be loaded at all
> by default, because why the f*ck should it? And what the hell should a
> microsoft signature have to do with *anything*?

So far? Nothing.

>  - before loading any third-party module, you'd better make sure you
> ask the user for permission. On the console. Not using keys. Nothing
> like that. Keys will be compromised. Try to limit the damage, but more
> importantly, let the user be in control.

So some sort of blocking insmod that waits for a sysrq input? I spent 
some time thinking about that, but then there's people who want 
automated installs on systems with bizarre storage hardware that depends 
on out of tree drivers. Like I said, *I'm* absolutely fine with not 
supporting out of tree drivers at all.

>  - encourage things like per-host random keys - with the stupid UEFI
> checks disabled entirely if required. They are almost certainly going
> to be *more* secure than depending on some crazy root of trust based
> on a big company, with key signing authorities that trust anybody with
> a credit card. Try to teach people about things like that instead.
> Encourage people to do their own (random) keys, and adding those to
> their UEFI setups (or not: the whole UEFI thing is more about control
> than security), and strive to do things like one-time signing with the
> private key thrown out entirely. IOW try to encourage *that* kind of
> "we made sure to ask the user very explicitly with big warnings and
> create his own key for that particular module" security. Real
> security, not "we control the user" security.

Yes, ideally people will engage in self-signing and distributions will 
have mechanisms for dealing with that.

> Sure, users will screw that up too. They'll want to load crazy nvidia
> binary modules etc crap. But make it *their* decision, and under
> *their* control, instead of trying to tell the world about how this
> should be blessed by Microsoft.

We can block third party modules by default, but they'll still be 
trusting Microsoft by default.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [GIT PULL] Load keys from signed PE binaries

[Matthew Garrett]

On Mon, Feb 25, 2013 at 08:43:59PM -0800, Linus Torvalds wrote:
> On Mon, Feb 25, 2013 at 8:23 PM, Matthew Garrett <mjg59@srcf.ucam.org> wrote:
> >
> > If the user has explicitly enrolled a hash then they're stepping outside
> > the trust model.
> 
> This is the kind of totally bogus crap that no sane person should ever
> spout. Stop it.
> 
> If the user has explicitly enrolled a hash, then that should be the
> *primary* trust model, dammit. That should be very much what you
> should care about first and foremost, and that should be your goal in
> life. That's when the user says "I'm in control of my own machine, and
> I want to trust *this*".

The user has stepped outside the original trust model ("I trust anything 
signed by Microsoft and only things signed by Microsoft") and into a new 
one ("I trust things that I say I trust"). That's a great thing for a 
user to do, but it also means that once the user's done it we don't need 
to give a fuck about what Microsoft think. They're irrelevant once the 
user's made that choice.

> It's not about "stepping outside of the trust model". Quite the
> reverse. It's about actually being *part* of the trust model, and
> taking control of your own machine. It's the *good* scenario. It's
> what you should encourage users to do.

I wholeheartedly agree.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [GIT PULL] Load keys from signed PE binaries

[Theodore Ts'o]

On Tue, Feb 26, 2013 at 02:55:32PM +1000, Dave Airlie wrote:
> 
> So it would be nice if LF could undertake to go and talk to Microsoft,
> and get vague opinions turned into something real.

Uh, folks like James and Greg K-H have talked to folks at
Microsoft.... I haven't talked to the folks at Microsoft personally,
but my understanding is that did _not_ tell us we had to do what
Matthew claims other folks at Mircrosoft have claimed that we have to
do, "or else".

> Ted you might be at liberty to get a chromebook pixel from google, but
> that isn't going to help the other X% of users who have a PC they want
> to use Linux on, and maybe boot Windows to do their taxes.

The point is that users will have choices.  It wasn't the end of the
world when some laptop manufacturers shipped devices that required
crappy Nvidia drivers.  I just simply chose not to buy laptops that
were crippled with the Optimus chipset, and purchased laptops that
used Intel graphics instead.  That's the free market at work.

Yes, it's sad that some users got stuck buying hardware which screwed
them over and made it very hard or impossible to use bleeding edge
kernels.  It's too bad some people had to learn the hard way.  The
good news though is that people who did do their due diligence could
purchase open hardware, and not get screwed by peripherals that
required proprietary drivers, whether they be WiFi or Graphics
drivers.

Of course, there are still crappy laptops that require proprietary
drivers, or for which no Linux drivers exist at all.  There's a reason
why I buy Thinkpads and not Sony laptops.  Similarly, the good news is
that there are open x86 devices being sold right now, post Windows-8,
which don't require us to be beholden to Microsoft.  Yes, there will
be users who buy the locked down crap.  There are also users who buy
Sony laptops.  Sometimes, we can't help everyone, and somtimes, it's
better not to encourage users to use hardware that require propietary
drivers, but to rather incentize them to use open hardware instead.

Regards,

	     	       		      	 - Ted

Re: [GIT PULL] Load keys from signed PE binaries

[Theodore Ts'o]

Dave,

Here's a further thought, extending on the analogy with closed
graphics hardware which requires proprietary drivers.  We _could_ have
made life easier for users who had the misfortune of purchasing closed
hardware.  We could have tied ourselves in knots and promulgated a
stable kernel ABI, so that Nvidia and ATI/AMD could more easly inflict
proprietary binary blob drivers just like they do for Windows.  We
chose not to screw ourselves over that way, even though it meant that
some users had a harder time of it.

Remember, before Intel came out with their graphics chips, for a while
it seemed that there were very grahpics options with decent
performance available that didn't require propietary drivers.  There
was a while when things looked pretty bleak.  Yet we didn't cave, and
eventually, life got better and more open options came on the scene.

Yet in the case of Secure Boot, everyone is assuming that Windows 8
will be a success, and that Microsoft will continue to dominate x86
client machines, and there will be no significant numbers of machines
that won't be locked down to Microsoft whims.  And so, we should run
up the white flag of surrender, and do everything that Microsoft
_might_ possibly require lest they capriciously and arbitrary decide
to revoke Linux distro's keys.

Linux distributions can do whatever they want, including locking down
kernel ABI's like they did for enterprise kernels (and I don't need to
tell people how painful that was for Linux distros).  But we didn't do
that for upstream kernels; instead, we pushed for open source device
drivers, and open hardware.  It took years, and we're still not 100%
successful, but we've made incredible progress, to the point where
we're no longer stressed out about device drivers any more; we just
avoid the proprietary crap, and it's not so hard to do that.

Maybe there's a lesson to be drawn from that which can be applied to
the Secure Boot mess.

Regards,

						- Ted

Re: [GIT PULL] Load keys from signed PE binaries

[Raymond Jennings]

Just curious here, but is this as much of an issue if a user is
somehow able to take ownership of his own machine?

I'm assuming this is related to TPM somehow.

Re: [GIT PULL] Load keys from signed PE binaries

[Matthew Garrett]

On Tue, Feb 26, 2013 at 02:07:22AM -0800, Raymond Jennings wrote:
> Just curious here, but is this as much of an issue if a user is
> somehow able to take ownership of his own machine?

No, if you're doing your own key management then it's no problem at 
all.

> I'm assuming this is related to TPM somehow.

No, completely unrelated.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [GIT PULL] Load keys from signed PE binaries

[Jiri Kosina]

On Mon, 25 Feb 2013, David Howells wrote:

>  (G) Suspend to disk.  This is not permitted if it's possible to then alter
>      the image and resume it.

Tangetial to this discussion, but worth mentioning anyway: this can be 
solved in a secure way in cooperation with trusted bootloader (such as 
shim); bootloader can be (re-)generating a new keypair on each and every 
boot, providing it to kernel. Kernel then signs the hibernation image and 
discards the private key.

During resume, the image signature (as public key still exists) can be 
verified, and new keypair is generated for potential subsequent 
hibernation again.
The public key is preserved in trusted UEFI variable, giving it the 
exactly same level of security as for example MOK has.

This still has some challenges (having enough entropy available for 
keypair generation in bootloader is unlikely, but PRNG might be 
sufficient), but it is doable.

-- 
Jiri Kosina
SUSE Labs

Re: [GIT PULL] Load keys from signed PE binaries

[Raymond Jennings]

My two cents on this subject btw is that anything to do with
Microsoft's intentions or plans is an issue of policy that belongs
entirely in userspace.

"mechanism, not policy"

Besides, what do modules have to do with this if we're talking about
UEFI?  Doesn't the kernel have to be loaded before modules are even an
issue?

Pardon me for being lost, just tyring to follow this.

Re: [GIT PULL] Load keys from signed PE binaries

[David Howells]

Greg KH <gregkh@linuxfoundation.org> wrote:

> >  (6) To maintain secure boot mode, the kernel must be signed and the boot
> >      loader must check the signature on it.  The key must be either compiled
> >      into the bootloader (and thus validated by the bootloader signature) or
> >      must reside in the UEFI database.
> > 
> >      [*] Note: This step is simplified a bit.
> 
> That's all fine, and now your machine can boot both Linux and Windows
> wonderfully.  Distros have shipped code doing this for a short while now
> thanks to Matthew's and other developer's effort in writing a UEFI
> bootloader / shim that Microsoft has signed.
> 
> >  (7) To maintain secure boot mode, the kernel modules must be signed and the
> >      kernel must check the signature on them.  The key must be compiled into
> >      the kernel or the bootloader or must reside in the UEFI database.
> 
> Wait right here.  This is NOT mandated by UEFI, nor by anyone else.  It
> might be a nice thing that some people and companies want to implement,
> but please don't think that some external entity is requiring that Linux
> implement this, that is not true.

What's the point in having the bootloader check the signature on a kernel
(which you say is fine) if you then permit it to be modified arbitrarily once
it is running?  If you don't have signed modules then there's no point having
signed kernels (assuming you don't disable module loading).

David

Re: [GIT PULL] Load keys from signed PE binaries

[Vivek Goyal]

On Tue, Feb 26, 2013 at 04:57:47AM +0000, Matthew Garrett wrote:

[..]
> >  - encourage things like per-host random keys - with the stupid UEFI
> > checks disabled entirely if required. They are almost certainly going
> > to be *more* secure than depending on some crazy root of trust based
> > on a big company, with key signing authorities that trust anybody with
> > a credit card. Try to teach people about things like that instead.
> > Encourage people to do their own (random) keys, and adding those to
> > their UEFI setups (or not: the whole UEFI thing is more about control
> > than security), and strive to do things like one-time signing with the
> > private key thrown out entirely. IOW try to encourage *that* kind of
> > "we made sure to ask the user very explicitly with big warnings and
> > create his own key for that particular module" security. Real
> > security, not "we control the user" security.
> 
> Yes, ideally people will engage in self-signing and distributions will 
> have mechanisms for dealing with that.

So even if a user installs its own keys in UEFI to boot self signed
shim, kernel and modules, I am assuming that we will still need to
make sure kexec does not load and run an unsigned kernel? (Otherwise
there is no point in installing user keys in UEFI and there is an
easy way to bypass it). 

Thanks
Vivek

Re: [GIT PULL] Load keys from signed PE binaries

[Vivek Goyal]

On Tue, Feb 26, 2013 at 10:30:45AM -0500, Vivek Goyal wrote:
> On Tue, Feb 26, 2013 at 04:57:47AM +0000, Matthew Garrett wrote:
> 
> [..]
> > >  - encourage things like per-host random keys - with the stupid UEFI
> > > checks disabled entirely if required. They are almost certainly going
> > > to be *more* secure than depending on some crazy root of trust based
> > > on a big company, with key signing authorities that trust anybody with
> > > a credit card. Try to teach people about things like that instead.
> > > Encourage people to do their own (random) keys, and adding those to
> > > their UEFI setups (or not: the whole UEFI thing is more about control
> > > than security), and strive to do things like one-time signing with the
> > > private key thrown out entirely. IOW try to encourage *that* kind of
> > > "we made sure to ask the user very explicitly with big warnings and
> > > create his own key for that particular module" security. Real
> > > security, not "we control the user" security.
> > 
> > Yes, ideally people will engage in self-signing and distributions will 
> > have mechanisms for dealing with that.
> 
> So even if a user installs its own keys in UEFI to boot self signed
> shim, kernel and modules, I am assuming that we will still need to
> make sure kexec does not load and run an unsigned kernel? (Otherwise
> there is no point in installing user keys in UEFI and there is an
> easy way to bypass it). 

As I am kind of lost in the long mail thread, so I will ask. If a user
installs its own keys in UEFI database and boots self signed linux
kernel, will we still make sure that no unsigned code can be run at
ring 0 (without explicitly asking user on console).

Thanks
Vivek

Re: [GIT PULL] Load keys from signed PE binaries

[Kent Yoder]

On Tue, Feb 26, 2013 at 4:21 AM, Matthew Garrett <mjg59@srcf.ucam.org> wrote:
> On Tue, Feb 26, 2013 at 02:07:22AM -0800, Raymond Jennings wrote:
>> Just curious here, but is this as much of an issue if a user is
>> somehow able to take ownership of his own machine?
>
> No, if you're doing your own key management then it's no problem at
> all.
>
>> I'm assuming this is related to TPM somehow.
>
> No, completely unrelated.

  Almost completely.  As Matthew I'm sure knows, TPM is also used to
establish a chain of trust, but not using signed
firmware/kernel/modules, but chained hashes that are later signed
using the TPM.  It does avoid the issue of embedding keys from a
centralized authority in your box's firmware.

Kent

> --
> Matthew Garrett | mjg59@srcf.ucam.org
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: [GIT PULL] Load keys from signed PE binaries

[Greg KH]

On Tue, Feb 26, 2013 at 03:11:41PM +0000, David Howells wrote:
> Greg KH <gregkh@linuxfoundation.org> wrote:
> 
> > >  (6) To maintain secure boot mode, the kernel must be signed and the boot
> > >      loader must check the signature on it.  The key must be either compiled
> > >      into the bootloader (and thus validated by the bootloader signature) or
> > >      must reside in the UEFI database.
> > > 
> > >      [*] Note: This step is simplified a bit.
> > 
> > That's all fine, and now your machine can boot both Linux and Windows
> > wonderfully.  Distros have shipped code doing this for a short while now
> > thanks to Matthew's and other developer's effort in writing a UEFI
> > bootloader / shim that Microsoft has signed.
> > 
> > >  (7) To maintain secure boot mode, the kernel modules must be signed and the
> > >      kernel must check the signature on them.  The key must be compiled into
> > >      the kernel or the bootloader or must reside in the UEFI database.
> > 
> > Wait right here.  This is NOT mandated by UEFI, nor by anyone else.  It
> > might be a nice thing that some people and companies want to implement,
> > but please don't think that some external entity is requiring that Linux
> > implement this, that is not true.
> 
> What's the point in having the bootloader check the signature on a kernel
> (which you say is fine) if you then permit it to be modified arbitrarily once
> it is running?  If you don't have signed modules then there's no point having
> signed kernels (assuming you don't disable module loading).

I'm not saying that it isn't something nice to have, I really like
signed kernel modules.  I'm saying that the key-signing of our Linux
shim bootloader is not dependant on having signed kernel modules, that's
all.  This has been proven by the fact that we have gotten bootloaders
signed without having this functionality in the kernel at the time.

thanks,

greg k-h

Re: [GIT PULL] Load keys from signed PE binaries

[Peter Jones]

On Mon, Feb 25, 2013 at 11:45:21PM -0500, Theodore Ts'o wrote:
> On Tue, Feb 26, 2013 at 02:25:55PM +1000, Dave Airlie wrote:
> > 
> > Its a simple argument, MS can revoke our keys for whatever reason,
> > reducing the surface area of reasons for them to do so seems like a
> > good idea. Unless someone can read the mind of the MS guy that
> > arbitrarily decides this in 5 years time, or has some sort of signed
> > agreement, I tend towards protecting the users from having their Linux
> > not work anymore, because we were scared of a PE loader in the kernel.
> 
> If Microsoft will revoke keys for whatever reason they want, without
> any regard to the potential PR and legal consequences to Microsoft,
> there's absolutely **nothing** you can do, short of choosing to use
> more open hardware (for example, like the Chromebook Pixel).

No, no, no.  Quit saying nobody knows.  We've got a pretty good idea -
we've got a contract with them, and it says they provide the signing
service, and under circumstances where the thing being signed is found
to enable malware that circumvents Secure Boot, we'll fix it so it can't
be, and we've got a certain amount of time to do so, and processes for
working with them, and then at that time blacklists will be issued.
This is not the precise language from that contract, and I'm not going to
go into specifics here.

So in our eyes, we've got a choice between excluding unsigned modules from
the start, or waiting until there's a very quickly approaching deadline.
Obviously, for the distributions that Matthew, David, and I work on,
we've chosen protecting them from the start, and some other distributions
have chosen differently.  One might guess that those who have chosen not
to do so are expecting that we'll have come up with a solution before their
deadline day happens.

So that's where we're coming from, in terms of requiring signatures on
modules at all.  We're also in a position where some of our customers and
hardware partners see a need to load binary-only modules, and we don't want
any part in signing or distributing those, for a variety of reasons.  So
we're looking for a mechanism to allow that, and this is what we've come
up with as a technical solution.

Would I like to see the user in control?  Yes, that's why I've put time
and effort into toolchains for users doing their own signing from SB on
down.  I completely agree that any degree to which users can be
convinced to manage their security would be a good thing.  But I don't
think I can convince all that many of my users to do so, and I think a
lot of them are still going to see a need for loading modules like this.

> If you're that terrified of the completely arbitrary and capricious
> Microsoft guy having us by the short hairs, why aid and abet Microsoft
> control-freak model?

That description entirely misrepresents our concern.

-- 
        Peter

Re: [GIT PULL] Load keys from signed PE binaries

[Florian Weimer]

* Matthew Garrett:

> On Mon, Feb 25, 2013 at 10:25:08PM -0500, Theodore Ts'o wrote:
>> On Tue, Feb 26, 2013 at 03:13:38AM +0000, Matthew Garrett wrote:
>> > 
>> > Because Microsoft have indicated that they'd be taking a reactive 
>> > approach to blacklisting and because, so far, nobody has decided to 
>> > write the trivial proof of concept that demonstrates the problem.
>> 
>> Microsoft would take a severe hit both from a PR perspective, as well
>> as incurring significant legal risks if they did that in certain
>> jourisdictions --- in particular, I suspect in Europe, if Microsoft
>> were to break the ability of Linux distributions from booting, it
>> would be significantly frowned upon.
>
> If a Linux vendor chose to knowingly breach the obligations they agreed 
> to, you don't think there'd be any PR hit?

I'm sure many folks have read <http://mjg59.dreamwidth.org/12368.html>
("Implementing UEFI Secure Boot in Fedora", 2012-30-05) and similar
analysis and came away with the impression of a rather open, automated
signing process, like we had/have for ActiveX controls and Java
Webstart applications.  This may have helped to increase acceptance of
Microsoft Secure Boot in the technical community.  But lately, in
direct contradiction to earlier descriptions of the process, a lot of
talk about "obligations" has appeared.  I understand that you cannot
go into specifics, but this situation is rather unfortunate for all of
us.

>> So Microsoft may have privately threatened this to certain Red Hat
>> attendees (threats are cheap, but it's not obvious that they would
>> necessarily follow through on this threat.
>
> You're happy advising Linux vendors that they don't need to worry about 
> module signing because it's "not obvious" that Microsoft would actually 
> enforce the security model they've spent significant money developing 
> and advertising?

What are the security objectives for UEFI Secure Boot and the
Microsoft implementation?  What are Microsoft's review critera for
signing and revoking drivers under the UEFI third-party market place
authority?  Is its existence even documented?

Re: [GIT PULL] Load keys from signed PE binaries

[Florian Weimer]

* Theodore Ts'o:

> On Tue, Feb 26, 2013 at 02:25:55PM +1000, Dave Airlie wrote:
>> 
>> Its a simple argument, MS can revoke our keys for whatever reason,
>> reducing the surface area of reasons for them to do so seems like a
>> good idea. Unless someone can read the mind of the MS guy that
>> arbitrarily decides this in 5 years time, or has some sort of signed
>> agreement, I tend towards protecting the users from having their Linux
>> not work anymore, because we were scared of a PE loader in the kernel.
>
> If Microsoft will revoke keys for whatever reason they want, without
> any regard to the potential PR and legal consequences to Microsoft,
> there's absolutely **nothing** you can do, short of choosing to use
> more open hardware (for example, like the Chromebook Pixel).

| No, there's no way to set the legacy boot as the default option.

<https://plus.google.com/100479847213284361344/posts/QhmBpn5GNE9>

So non-interactive booting of alternative operating systems is *not*
supported.  This is way more restrictive than any x86 UEFI device I've
heard of (even in the face of a potential revocation of the boot
loader by Microsoft).

Re: [GIT PULL] Load keys from signed PE binaries

[Matthew Garrett]

On Tue, Feb 26, 2013 at 08:30:17PM +0100, Florian Weimer wrote:

> I'm sure many folks have read <http://mjg59.dreamwidth.org/12368.html>
> ("Implementing UEFI Secure Boot in Fedora", 2012-30-05) and similar
> analysis and came away with the impression of a rather open, automated
> signing process, like we had/have for ActiveX controls and Java
> Webstart applications.  This may have helped to increase acceptance of
> Microsoft Secure Boot in the technical community.  But lately, in
> direct contradiction to earlier descriptions of the process, a lot of
> talk about "obligations" has appeared.  I understand that you cannot
> go into specifics, but this situation is rather unfortunate for all of
> us.

It's open. If your code ends up signed and is then used to compromise 
the security of other signed operating systems, you're likely to be 
blacklisted. That can't surprise anyone, can it?

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [GIT PULL] Load keys from signed PE binaries

[Matthew Garrett]

On Tue, Feb 26, 2013 at 08:40:53PM +0100, Florian Weimer wrote:
> | No, there's no way to set the legacy boot as the default option.
> 
> <https://plus.google.com/100479847213284361344/posts/QhmBpn5GNE9>
> 
> So non-interactive booting of alternative operating systems is *not*
> supported.  This is way more restrictive than any x86 UEFI device I've
> heard of (even in the face of a potential revocation of the boot
> loader by Microsoft).

It's supported as long as you use Google's bootloader rather than a 
legacy one, but you're still stuck with either a 30-second boot delay or 
hitting ctrl+d and there's no way to install your own keys without 
disassembling the machine and physically disabling the write-protection 
on the firmware. It's certainly more hostile than any UEFI Secure Boot 
system I've found.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [GIT PULL] Load keys from signed PE binaries

[Florian Weimer]

* Matthew Garrett:

> On Mon, Feb 25, 2013 at 03:28:32PM +0100, Florian Weimer wrote:
>
>> But what puzzles me most is why anyone would assume that the UEFI
>> application signing process somehow ensures that the embedded
>> certificate is non-malicious.  We cannot even track it back to the
>> submitter because the third-pary market place UEFI authority only
>> issues pseudonymous proxy certificates.  This utterly useless for any
>> purpose whatsoever, with the notable exception of avoding one
>> additional step when setting up a dual-boot machine (which will not
>> even work reliably until we switch to overwriting the Windows boot
>> loader, like in the pre-UEFI days).
>
> If your firmware trusts objects signed by Microsoft, you have to assume 
> that objects signed by Microsoft are trustworthy. There's no way to 
> build a security model otherwise. Are Microsoft trustworthy? We don't 
> know. If you don't trust Microsoft, remove their key from db.

"Trust" is such an overloaded concept.  I think there are several
aspects here.

The UEFI firmware performs cryptographic validation and only executes
code if successful.

Symantec performs identify verification (the $99 fee) and Microsoft
relies on that.  Microsoft also conducts some review before signing
UEFI drivers.  This actually catches some badness (unintentional
here):

| What Happened to KeyTool.efi?
|
| Originally this was going to be part of our signed release kit.
| However, during testing Microsoft discovered that because of a bug in
| one of the UEFI platforms, it could be used to remove the platform key
| programmatically, which would rather subvert the UEFI security system.
| Until we can resolve this (we’ve now got the particular vendor in the
| loop), they declined to sign KeyTool.efi although you can, of course,
| authorize it by hash in the MOK variables if you want to run it.
 
<http://blog.hansenpartnership.com/linux-foundation-secure-boot-system-released/>

But this review process loses its teeth if the binary just contains an
X.509 certificate which is used later to allow the execution of other
code (either directly, or as the result of a rather complex
interaction of various UEFI drivers, doesn't really matter).

Microsoft never sees the whole code that will be run, and it's totally
open what the driver will actually do when fed with the right data.
At this point, whether anybody trusts Microsoft is completely besides
the point.  They simply don't know.  Their UEFI driver signature is
about as meaningful as a signature from a timestamping service
(particularly since it is pseudonymous).  But they still have
revocation.

I think this is not a good position for them, for us, or for our
users.  All this cryptographic indirection is rather brittle, and it
is totally unclear who is accountable for what.

>> Seriously, folks, can we go back one step and discuss what problem you
>> are trying to solve?  Is it about allowing third-party kernel modules
>> in an environment which does not allow unsigned ring 0 code execution?
>
> The problem I'm trying to solve is "Don't permit Linux to be used as a 
> bootloader for backdoored versions of other operating systems".

If that's the goal, shouldn't we disable KVM support as well?
(Without hardware virtualization support, the user would hopefully
perceive the significant slowdown.)

Re: [GIT PULL] Load keys from signed PE binaries

[Florian Weimer]

* Linus Torvalds:

> So here's what I would suggest, and it is based on REAL SECURITY and
> on PUTTING THE USER FIRST instead of your continual "let's please
> microsoft by doing idiotic crap" approach.

I think the real question is this one: Is there *any* device out there
which comes with Microsoft Secure Boot enabled, but doesn't have a
copy of Windows 8 on it?

I guess there isn't.  So Secure Boot support is only required for
supporting dual-booting Windows 8, while still retaining the automated
recovery capabilities (which might well remove the Linux installation
on the same box).

Without dual-booting, there is currently no reason whatsoever to
enable UEFI Secure Boot (or the Microsoft variant).  Not providing a
signed boot loader forces the user to configure the device in a way
that ensures long-term supportability and feature stability (i.e.,
they don't suffer when someone decides to introduce further
restrictions under CAP_COMPROMISE_KERNEL).

Unfortuantely, almost all people I talked to *want* secure boot,
presumably because security is good.  Many of them hate the Microsoft
key (but wouldn't want to own the key, either), but the proposed
alternatives, such as distro-specific keys, are impractical.  Do we
really want systems on which you cannot install Fedora once you have
installed Debian?

> So instead of pleasing microsoft, try to see how we can add real security:
>
>  - a distro should sign its own modules AND NOTHING ELSE by default.

I strongly agree with that (but obviously not the wording, *ahem*).
Actually, we already sign our own kernel modules (and all the software
we ship) in one way or the other.  Some of us even sign a lot of
third-party software which we haven't built from source.

>  - before loading any third-party module, you'd better make sure you
> ask the user for permission. On the console. Not using keys. Nothing
> like that. Keys will be compromised. Try to limit the damage, but more
> importantly, let the user be in control.

This needs a trusted input/output path to the user.  Currently, this
seems difficult to provide once arbitrary userspace code has run as
root.  Hence the round-trip through the UEFI pre-boot environment.

One thing that would be neat is an assurance that if you boot some
image over PXE, it doesn't do any harm to your system.  This isn't
something Microsoft Secure Boot promises at the moment because a
signed boot loader can easily lead to an initrd which wipes your hard
disk.  It's really hard to get there, but at least it would be
something useful.  Similarly, server firmware in a datacenter could
validate the recovery image before executing.  (Actually, I view boot
path validation mainly as a server technology—for clients, you just
save $1 for the known-good, read-only recovery medium.)

Re: [GIT PULL] Load keys from signed PE binaries

[Florian Weimer]

* Chris Friesen:

> On 02/25/2013 10:14 AM, Matthew Garrett wrote:
>> Windows 8 will not load unsigned drivers if Secure Boot is enabled.
>
> For reference:
>
> http://msdn.microsoft.com/en-us/library/windows/desktop/hh848062%28v=vs.85%29.aspx

Thanks.  Do you know perchance of any other Microsoft documentation in
this area, that is, their PKI architecture, the signing and revocation
policies, or even security objectives for the Secure Boot
implementation?

The Windows 8 logo requirements are pretty thin on this and only
specify the "Microsoft Windows Production PCA 2011" (which is used to
sign the Windows boot loader).  Policy-wise, I've seen very little
published information (most of it is hearsay), and as to the
objectives, I'm really in the dark.

Re: [GIT PULL] Load keys from signed PE binaries

[Peter Jones]

On Tue, Feb 26, 2013 at 10:30:46PM +0100, Florian Weimer wrote:
> * Linus Torvalds:
> 
> > So here's what I would suggest, and it is based on REAL SECURITY and
> > on PUTTING THE USER FIRST instead of your continual "let's please
> > microsoft by doing idiotic crap" approach.
> 
> I think the real question is this one: Is there *any* device out there
> which comes with Microsoft Secure Boot enabled, but doesn't have a
> copy of Windows 8 on it?
> 
> I guess there isn't.  So Secure Boot support is only required for
> supporting dual-booting Windows 8, while still retaining the automated
> recovery capabilities (which might well remove the Linux installation
> on the same box).
> 
> Without dual-booting, there is currently no reason whatsoever to
> enable UEFI Secure Boot (or the Microsoft variant).

It prevents a form of malware which exists in the wild.  I think that's
enough reason to want *something*, though SB isn't necessarily what
we'd have dreamed of.  Nevertheless, SB is what we've got, and as such
is why we've been working on how to use it meaningfully.

This all seems pretty orthogonal to the question at hand, of course.

-- 
        Peter

Re: [GIT PULL] Load keys from signed PE binaries

[Geert Uytterhoeven]

On Tue, Feb 26, 2013 at 5:43 AM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> On Mon, Feb 25, 2013 at 8:23 PM, Matthew Garrett <mjg59@srcf.ucam.org> wrote:
>> If the user has explicitly enrolled a hash then they're stepping outside
>> the trust model.
>
> This is the kind of totally bogus crap that no sane person should ever
> spout. Stop it.
>
> If the user has explicitly enrolled a hash, then that should be the
> *primary* trust model, dammit. That should be very much what you
> should care about first and foremost, and that should be your goal in
> life. That's when the user says "I'm in control of my own machine, and
> I want to trust *this*".
>
> It's not about "stepping outside of the trust model". Quite the
> reverse. It's about actually being *part* of the trust model, and
> taking control of your own machine. It's the *good* scenario. It's
> what you should encourage users to do.

Indeed.

But explicitly enrolling your own hash is not enough to take control.
You must also remove the other hashes that are already present, since
you don't control what's signed using the corresponding private keys.

BTW, I assume UEFI checks itself if enrolled hashes have been revoked,
so it must phone home to some server? That must be disabled as well.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [GIT PULL] Load keys from signed PE binaries

[Peter Jones]

On Tue, Feb 26, 2013 at 10:57:38PM +0100, Geert Uytterhoeven wrote:

> BTW, I assume UEFI checks itself if enrolled hashes have been revoked,
> so it must phone home to some server? That must be disabled as well.

No.  Quit fearmongering.

--
	Peter

Re: [GIT PULL] Load keys from signed PE binaries

[Chris Friesen]

On 02/26/2013 03:40 PM, Florian Weimer wrote:
> * Chris Friesen:
>
>> On 02/25/2013 10:14 AM, Matthew Garrett wrote:
>>> Windows 8 will not load unsigned drivers if Secure Boot is enabled.
>>
>> For reference:
>>
>> http://msdn.microsoft.com/en-us/library/windows/desktop/hh848062%28v=vs.85%29.aspx
>
> Thanks.  Do you know perchance of any other Microsoft documentation in
> this area, that is, their PKI architecture, the signing and revocation
> policies, or even security objectives for the Secure Boot
> implementation?

Sorry, I got nothing. :)  I just happened to stumble over the above.

Chris

Re: [GIT PULL] Load keys from signed PE binaries

[Al Viro]

On Tue, Feb 26, 2013 at 04:40:53PM -0500, Peter Jones wrote:

> It prevents a form of malware which exists in the wild.  I think that's
> enough reason to want *something*, though SB isn't necessarily what
> we'd have dreamed of.  Nevertheless, SB is what we've got, and as such
> is why we've been working on how to use it meaningfully.

*snerk*

"We need to do something.  This is something.  Let's do it"

Re: [GIT PULL] Load keys from signed PE binaries

[ownssh]

David Howells <dhowells <at> redhat.com> writes:

> 
> 
> Florian Weimer <fw <at> deneb.enyo.de> wrote:
> 
> > Seriously, folks, can we go back one step and discuss what problem you
> > are trying to solve?  Is it about allowing third-party kernel modules
> > in an environment which does not allow unsigned ring 0 code execution?
> 
> Let me try and lay things out:
> 
>  (1) Like it or not, the reality is that machines exist that have UEFI secure

I think, redhat should have their own root key to sign binary files.
Bootloader of install media can be sign by MS certificates, but only use to add
the redhat root key to UEFI database before install.
It will solve many problems like MS blacklist the keys although redhat said MS
wont do that forever.

And, even you do the all things of A-G, it still wont safe because many
vulnerabilities can let the attacker enter ring0 only use to exploit the exist
signed kernel module or kernel itself.

Re: [GIT PULL] Load keys from signed PE binaries

[James Courtier-Dutton]

On 27 February 2013 09:35, ownssh <ownssh@gmail.com> wrote:
> David Howells <dhowells <at> redhat.com> writes:
>
>>
>>
>> Florian Weimer <fw <at> deneb.enyo.de> wrote:
>>
>> > Seriously, folks, can we go back one step and discuss what problem you
>> > are trying to solve?  Is it about allowing third-party kernel modules
>> > in an environment which does not allow unsigned ring 0 code execution?
>>
>> Let me try and lay things out:
>>
>>  (1) Like it or not, the reality is that machines exist that have UEFI secure
>
> I think, redhat should have their own root key to sign binary files.
> Bootloader of install media can be sign by MS certificates, but only use to add
> the redhat root key to UEFI database before install.
> It will solve many problems like MS blacklist the keys although redhat said MS
> wont do that forever.
>
> And, even you do the all things of A-G, it still wont safe because many
> vulnerabilities can let the attacker enter ring0 only use to exploit the exist
> signed kernel module or kernel itself.
>

One way to judge if this is a good solution or not is to list what the
threats are, and see how well the solution mitigates those.
I will list a few I would like:
1) Tamper evindence.
2) Fast trust revokation and correction.
3) Trust based on date. I trust everything from X that I put on my
system 2 weeks ago, but one week ago X got hacked, so don't trust
anything new from them until the hack has been stopped and the
revokation/correction steps have been completed.
E.g. the Bit9 case, where malware was able to be signed.

I think secure boot does a very week version of (1) and is very slow
at (2), and does not do (3).
The ARM version of secure boot is maybe slightly better, it does a
good job of (1) but at the expense some of (2).
I.e. the root certificate is in ROM on ARM and not EEPROM on x86.
It is difficult to tamper with ROM, so you have a much stronger tamper
evindence solution.
Unfortunately, if the root certificate in the ROM is compromised, you
cannot revoke it and correct it.

Kind Regards
				
James

Re: [GIT PULL] Load keys from signed PE binaries

[Alexander Holler]

Am 27.02.2013 11:17, schrieb James Courtier-Dutton:

> 3) Trust based on date. I trust everything from X that I put on my
> system 2 weeks ago, but one week ago X got hacked, so don't trust
> anything new from them until the hack has been stopped and the
> revokation/correction steps have been completed.
> E.g. the Bit9 case, where malware was able to be signed.

Which date? In reality dates are (mostly) defined as fixed points, but 
computers just don't have such.

E.g. currently you can't use modsign based on X.509 certificates if the 
date comes through USB, because modsign tries to load the certificate 
before before the USB stack comes up, which ends up with invalid dates 
(Not Before).
And changing the system date isn't that hard for an attacker if he is 
already able to do other bad things.

Regards,

Alexander

Re: [GIT PULL] Load keys from signed PE binaries

[James Courtier-Dutton]

On 27 February 2013 11:27, Alexander Holler <holler@ahsoftware.de> wrote:
> Am 27.02.2013 11:17, schrieb James Courtier-Dutton:
>
>
>> 3) Trust based on date. I trust everything from X that I put on my
>> system 2 weeks ago, but one week ago X got hacked, so don't trust
>> anything new from them until the hack has been stopped and the
>> revokation/correction steps have been completed.
>> E.g. the Bit9 case, where malware was able to be signed.
>
>
> Which date? In reality dates are (mostly) defined as fixed points, but
> computers just don't have such.
>
> E.g. currently you can't use modsign based on X.509 certificates if the date
> comes through USB, because modsign tries to load the certificate before
> before the USB stack comes up, which ends up with invalid dates (Not
> Before).
> And changing the system date isn't that hard for an attacker if he is
> already able to do other bad things.
>

Maybe date was not a good example.
I think a single chain of trust is risky.
Using multiple signatures on the same binary is better.
e.g. Redhat have signed it, but only load the module if both redhat
and Bit9 have signed it.
In this case, the risk it mitigated, as both Redhat and Bit9 have to
be hacked for the malware to get through.
Now, if a local administrator created a new signing key each time they
installed updates, and the system checked that both the redhat
signature and the local administrator signature were valid before
loading the module, this would give a form of signing based on date.
(the install date)
The local administrator could then quickly revoke the keys for a
particular day, and not have to wait for Redhat to revoke their keys.

Re: [GIT PULL] Load keys from signed PE binaries

[Geert Uytterhoeven]

On Tue, Feb 26, 2013 at 11:06 PM, Peter Jones <pjones@redhat.com> wrote:
> On Tue, Feb 26, 2013 at 10:57:38PM +0100, Geert Uytterhoeven wrote:
>
>> BTW, I assume UEFI checks itself if enrolled hashes have been revoked,
>> so it must phone home to some server? That must be disabled as well.
>
> No.  Quit fearmongering.

Good to know, thanks!

So revocation will only be done by the guest OS?
I.e. if I only boot my own trusted Linux, even if it's signed with the MS key,
the MS key _on my system_ will never be revoked?

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [GIT PULL] Load keys from signed PE binaries

[Matthew Garrett]

On Wed, Feb 27, 2013 at 01:32:30PM +0100, Geert Uytterhoeven wrote:

> So revocation will only be done by the guest OS?
> I.e. if I only boot my own trusted Linux, even if it's signed with the MS key,
> the MS key _on my system_ will never be revoked?

As long as you never apply any updates that will revoke that key.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [GIT PULL] Load keys from signed PE binaries

[Peter Jones]

On Wed, Feb 27, 2013 at 01:32:30PM +0100, Geert Uytterhoeven wrote:
> On Tue, Feb 26, 2013 at 11:06 PM, Peter Jones <pjones@redhat.com> wrote:
> > On Tue, Feb 26, 2013 at 10:57:38PM +0100, Geert Uytterhoeven wrote:
> >
> >> BTW, I assume UEFI checks itself if enrolled hashes have been revoked,
> >> so it must phone home to some server? That must be disabled as well.
> >
> > No.  Quit fearmongering.
> 
> Good to know, thanks!
> 
> So revocation will only be done by the guest OS?
> I.e. if I only boot my own trusted Linux, even if it's signed with the MS key,
> the MS key _on my system_ will never be revoked?

Something must apply the dbx update.  We'll certainly do so in Fedora and
RHEL, from userland, but you're certainly in a position to make it not
happen in your own trusted linux, and even on a Fedora or RHEL machine
you maintain.  But there's no "phoning home" involved - the plan is to
make that happen as a regular package update to shim-signed, so here you
go:

--- /etc/yum.conf.old	2013-02-27 09:10:25.181998268 -0500
+++ /etc/yum.conf	2013-02-27 09:10:34.423403583 -0500
@@ -21,3 +21,4 @@
 
 # PUT YOUR REPOS HERE OR IN separate files named file.repo
 # in /etc/yum.repos.d
+exclude=shim-signed

And as long as you never boot Windows on the thing, you're set.
-- 
        Peter

Re: [GIT PULL] Load keys from signed PE binaries

[Matthew Garrett]

On Wed, Feb 27, 2013 at 09:35:24AM +0000, ownssh wrote:

> I think, redhat should have their own root key to sign binary files.
> Bootloader of install media can be sign by MS certificates, but only use to add
> the redhat root key to UEFI database before install.

There's no way to update the UEFI key database without the update being 
signed by an already trusted key, so what you're proposing isn't 
possible.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [GIT PULL] Load keys from signed PE binaries

[Theodore Ts'o]

On Tue, Feb 26, 2013 at 11:54:51AM -0500, Peter Jones wrote:
> No, no, no.  Quit saying nobody knows.  We've got a pretty good idea -
> we've got a contract with them, and it says they provide the signing
> service, and under circumstances where the thing being signed is found
> to enable malware that circumvents Secure Boot

The question is what does "malware that circuments Secure Boot" mean?
Does starting up a hacked KVM and running Windows 8 under KVM so that
malare can be injected count as circumenting Secure Boot?  If so, will
you have to disable KVM, too?

What if someone implements a virtualization bootkit for Windows 8.
Will they revoke their own key?  Somehow, I doubt that....

						- Ted

Re: [GIT PULL] Load keys from signed PE binaries

[Eric W. Biederman]

Vivek Goyal <vgoyal@redhat.com> writes:

> On Tue, Feb 26, 2013 at 10:30:45AM -0500, Vivek Goyal wrote:
>> On Tue, Feb 26, 2013 at 04:57:47AM +0000, Matthew Garrett wrote:
>> 
>> [..]
>> > >  - encourage things like per-host random keys - with the stupid UEFI
>> > > checks disabled entirely if required. They are almost certainly going
>> > > to be *more* secure than depending on some crazy root of trust based
>> > > on a big company, with key signing authorities that trust anybody with
>> > > a credit card. Try to teach people about things like that instead.
>> > > Encourage people to do their own (random) keys, and adding those to
>> > > their UEFI setups (or not: the whole UEFI thing is more about control
>> > > than security), and strive to do things like one-time signing with the
>> > > private key thrown out entirely. IOW try to encourage *that* kind of
>> > > "we made sure to ask the user very explicitly with big warnings and
>> > > create his own key for that particular module" security. Real
>> > > security, not "we control the user" security.
>> > 
>> > Yes, ideally people will engage in self-signing and distributions will 
>> > have mechanisms for dealing with that.
>> 
>> So even if a user installs its own keys in UEFI to boot self signed
>> shim, kernel and modules, I am assuming that we will still need to
>> make sure kexec does not load and run an unsigned kernel? (Otherwise
>> there is no point in installing user keys in UEFI and there is an
>> easy way to bypass it). 
>
> As I am kind of lost in the long mail thread, so I will ask. If a user
> installs its own keys in UEFI database and boots self signed linux
> kernel, will we still make sure that no unsigned code can be run at
> ring 0 (without explicitly asking user on console).

The short version is what I said at the start.

Whatever kexec does should make sense outside of the context of UEFI and
secure boot.

The point of installing user keys in UEFI is so that the user has
control of when other keys are trusted.  So that the user is not
required to trust Microsoft, or anything signed by Microsoft.  So that
the user has control of the start of the boot process.

One way or another the bad-guys will figure out how to get into
ring0. UEFI secure boot at best means you can wrest back control of your
machine from the bad-guys after that happens.

What kexec checking signatures fundamentally does is make it hard for a
bad guy to pull a fast one and get you to boot a compromised kernel.
That is an interesting problem regardless of secure boot.

Eric

Re: [GIT PULL] Load keys from signed PE binaries

[Chris Friesen]

On 02/27/2013 09:24 AM, Theodore Ts'o wrote:
> On Tue, Feb 26, 2013 at 11:54:51AM -0500, Peter Jones wrote:
>> No, no, no.  Quit saying nobody knows.  We've got a pretty good idea -
>> we've got a contract with them, and it says they provide the signing
>> service, and under circumstances where the thing being signed is found
>> to enable malware that circumvents Secure Boot
>
> The question is what does "malware that circuments Secure Boot" mean?
> Does starting up a hacked KVM and running Windows 8 under KVM so that
> malare can be injected count as circumenting Secure Boot?  If so, will
> you have to disable KVM, too?

I could see an argument for KVM to require either a signed binary or 
else someone at the keyboard to explicitly okay loading the image. 
Anything else breaks the chain of trust.

It may be somewhat far-fetched, but I think it would be possible to take 
an existing secure-boot Win 8 install, turn it into a VM but with an 
infected kernel. Then install a signed Linux distro that runs the Win8 
VM as a guest.

At this point you've got a running infected Win8 install that is running 
on Secure Boot hardware but is actually running malware.

Admittedly this would be tricky to do reliably in a way that the user 
doesn't notice, so it may not actually be a real-world threat.

Chris

Re: [GIT PULL] Load keys from signed PE binaries

[Theodore Ts'o]

On Wed, Feb 27, 2013 at 11:36:09AM -0600, Chris Friesen wrote:
> ...
> At this point you've got a running infected Win8 install that is
> running on Secure Boot hardware but is actually running malware.
> 
> Admittedly this would be tricky to do reliably in a way that the
> user doesn't notice, so it may not actually be a real-world threat.

That's another thing which is extraordinarily vague.  What counts as
"user doesn't notice"?  If a whole bunch of kernel messages scroll by,
is that enough?  What if a Penguin jpg shows up for a minimum 5
seconds?  15 seconds?  30 seconds?

						- Ted

Re: [GIT PULL] Load keys from signed PE binaries

[Paolo Bonzini]

Il 27/02/2013 18:36, Chris Friesen ha scritto:
> On 02/27/2013 09:24 AM, Theodore Ts'o wrote:
>> On Tue, Feb 26, 2013 at 11:54:51AM -0500, Peter Jones wrote:
>>> No, no, no.  Quit saying nobody knows.  We've got a pretty good idea -
>>> we've got a contract with them, and it says they provide the signing
>>> service, and under circumstances where the thing being signed is found
>>> to enable malware that circumvents Secure Boot
>>
>> The question is what does "malware that circuments Secure Boot" mean?
>> Does starting up a hacked KVM and running Windows 8 under KVM so that
>> malare can be injected count as circumenting Secure Boot?  If so, will
>> you have to disable KVM, too?
> 
> I could see an argument for KVM to require either a signed binary or
> else someone at the keyboard to explicitly okay loading the image.
> Anything else breaks the chain of trust.

Not just the executable; the firmware would also need to be signed.

In fact, I think requiring signed KVM binaries and signed VM firmwares
makes sense in the long term, but you have to stop somewhere.

And BTW you can always emulate the instruction set instead of using
hardware virtualization.  This way the kernel is not involved.  It's a
slippery slope and leads you straight to the app store model and
restrictions on interpreters like Apple's.

Certainly an attack using unsigned modules is trivial, unlike one that
virtualizes the victim OS, and also much harder to discover
(virtualization is easy to detect by timing certain operations in the
guest).  Just for this reason, putting unsigned modules on the "no" side
makes much more sense than putting virtualization on the "no" side.

Paolo

> It may be somewhat far-fetched, but I think it would be possible to take
> an existing secure-boot Win 8 install, turn it into a VM but with an
> infected kernel. Then install a signed Linux distro that runs the Win8
> VM as a guest.
> 
> At this point you've got a running infected Win8 install that is running
> on Secure Boot hardware but is actually running malware.
> 
> Admittedly this would be tricky to do reliably in a way that the user
> doesn't notice, so it may not actually be a real-world threat.
> 
> Chris

Re: [GIT PULL] Load keys from signed PE binaries

[Chris Friesen]

On 02/27/2013 11:59 AM, Theodore Ts'o wrote:
> On Wed, Feb 27, 2013 at 11:36:09AM -0600, Chris Friesen wrote:
>> ...
>> At this point you've got a running infected Win8 install that is
>> running on Secure Boot hardware but is actually running malware.
>>
>> Admittedly this would be tricky to do reliably in a way that the
>> user doesn't notice, so it may not actually be a real-world threat.
>
> That's another thing which is extraordinarily vague.  What counts as
> "user doesn't notice"?  If a whole bunch of kernel messages scroll by,
> is that enough?  What if a Penguin jpg shows up for a minimum 5
> seconds?  15 seconds?  30 seconds?

I think it'd need to be "doesn't notice operationally when running the 
virtualized Windows install".

Anyone going through all the trouble to virtualize an existing install 
could probably arrange to have the target computer do the conversion at 
a time when nobody is likely to be around.

Chris

Re: [GIT PULL] Load keys from signed PE binaries

[Theodore Ts'o]

On Wed, Feb 27, 2013 at 01:21:03PM -0600, Chris Friesen wrote:
> 
> I think it'd need to be "doesn't notice operationally when running
> the virtualized Windows install".
> 
> Anyone going through all the trouble to virtualize an existing
> install could probably arrange to have the target computer do the
> conversion at a time when nobody is likely to be around.

It shouldn't be all that hard to avoid doing a full-fledged
conversion.  I've in the pat managed to configure KVM so that a
particular installation of Windows could be run either natively or
under KVM.  The hard part would be to make Windows not notice the
change in device drivers necessary, so trying to make this work with
paravirtualization would be tricky.  But if you aren't shooting for a
full performance, it shouldn't be that hard.

That being said, if someone were being employed by the NSA to attack
Iran, or by the MSS to attack the US Federal Government, or simply by
a russian firm wanting to make $$$ selling Viagra, they'd probably try
to shoot for figuring out some way to surrepticiously install the
paravirtualization drivers into an existing Windows install.  But this
is not a fundamental theoretical difficulty; just a practical one.)

       	 	     		 	     	    - Ted

Re: [GIT PULL] Load keys from signed PE binaries

[ownssh]

Matthew Garrett <mjg59 <at> srcf.ucam.org> writes:

> There's no way to update the UEFI key database without the update being 
> signed by an already trusted key, so what you're proposing isn't 
> possible.
> 

I confused.
Isn't custom mode can add user's own key?
> http://mjg59.dreamwidth.org/12368.html
> But I don't trust Microsoft
So I dont trust, I very worry MS will block the key they give in some day then
most fedora user need disable secure boot & update kernel and kmod signed
by that key.

I think secure boot should not control by MS, but if it's,
then it should not merge to linux kernel.

Re: [GIT PULL] Load keys from signed PE binaries

[Dave Airlie]

On Thu, Feb 28, 2013 at 1:24 AM, Theodore Ts'o <tytso@mit.edu> wrote:
> On Tue, Feb 26, 2013 at 11:54:51AM -0500, Peter Jones wrote:
>> No, no, no.  Quit saying nobody knows.  We've got a pretty good idea -
>> we've got a contract with them, and it says they provide the signing
>> service, and under circumstances where the thing being signed is found
>> to enable malware that circumvents Secure Boot
>
> The question is what does "malware that circuments Secure Boot" mean?
> Does starting up a hacked KVM and running Windows 8 under KVM so that
> malare can be injected count as circumenting Secure Boot?  If so, will
> you have to disable KVM, too?
>
> What if someone implements a virtualization bootkit for Windows 8.
> Will they revoke their own key?  Somehow, I doubt that....

Have you noticed that laptops rarely come with virtualisation enabled
in the BIOS?

Now you know why.

Dave.

Re: [GIT PULL] Load keys from signed PE binaries

[Geert Uytterhoeven]

On Wed, Feb 27, 2013 at 10:31 PM, Dave Airlie <airlied@gmail.com> wrote:
> On Thu, Feb 28, 2013 at 1:24 AM, Theodore Ts'o <tytso@mit.edu> wrote:
>> On Tue, Feb 26, 2013 at 11:54:51AM -0500, Peter Jones wrote:
>>> No, no, no.  Quit saying nobody knows.  We've got a pretty good idea -
>>> we've got a contract with them, and it says they provide the signing
>>> service, and under circumstances where the thing being signed is found
>>> to enable malware that circumvents Secure Boot
>>
>> The question is what does "malware that circuments Secure Boot" mean?
>> Does starting up a hacked KVM and running Windows 8 under KVM so that
>> malare can be injected count as circumenting Secure Boot?  If so, will
>> you have to disable KVM, too?
>>
>> What if someone implements a virtualization bootkit for Windows 8.
>> Will they revoke their own key?  Somehow, I doubt that....
>
> Have you noticed that laptops rarely come with virtualisation enabled
> in the BIOS?
>
> Now you know why.

I thought it was about market segmentation? Charge $$$ for the model with VT
enabled.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [GIT PULL] Load keys from signed PE binaries

[Paolo Bonzini]

Il 28/02/2013 07:27, Geert Uytterhoeven ha scritto:
> I thought it was about market segmentation? Charge $$$ for the model with VT
> enabled.

No, there's the Atom that doesn't come with virtualization extensions at
all.

But things like Bluepill are the reason why you have to enable VT manually.

Paolo

> Gr{oetje,eeting}s,
> 
>                         Geert

Re: [GIT PULL] Load keys from signed PE binaries

[Florian Weimer]

* Greg KH:

> On Tue, Feb 26, 2013 at 03:13:38AM +0000, Matthew Garrett wrote:
>> Because Microsoft have indicated that they'd be taking a reactive 
>> approach to blacklisting and because, so far, nobody has decided to 
>> write the trivial proof of concept that demonstrates the problem.
>
> So, once that proof is written, suddenly all of the working Linux
> distros's keys will be revoked?

The counterargument to that is that Microsoft will not proactively
revoke UEFI drivers, only drivers which are actually abused.

As far as I know, there is no public commitment to this revocation
policy.  It makes sense, given the limited revocation space, but
that's all.

> I don't buy it.  Yes, I understand this is your position, and has been
> all along, and _maybe_ you can extend it to "we should sign our kernel
> modules", but to take it farther than that, like the list David has
> described, is not required by anyone here.

It's a logical extrapolation based on the technical specification.
I've been guilty of the same mistake, if you want to call it that way.
Basically, we're making up concrete security objectives because the
existing documentation doesn't provide them, and write our code
according to that.  But we can easily guess wrong, in both directions.

In any case, there's another reading of the UEFI Secure Boot
requirements: you may run any code you wish after calling
ExitBootServices().  That could be an unsigned, traditional GRUB.  But
this will not generally address the issue of dual-booting Windows 8 in
such a way that Windows sees that the device has enabled Microsoft
Secure Boot.

Re: [GIT PULL] Load keys from signed PE binaries

[Chris Friesen]

On 02/28/2013 01:57 AM, Florian Weimer wrote:

> In any case, there's another reading of the UEFI Secure Boot
> requirements: you may run any code you wish after calling
> ExitBootServices().  That could be an unsigned, traditional GRUB.  But
> this will not generally address the issue of dual-booting Windows 8 in
> such a way that Windows sees that the device has enabled Microsoft
> Secure Boot.

Would it be possible to have a signed bootloader that allows booting 
Win8 from within the secure environment, or it could exit the secure 
environment and run unsigned grub?

Chris

Re: [GIT PULL] Load keys from signed PE binaries

[Florian Weimer]

* Chris Friesen:

> On 02/28/2013 01:57 AM, Florian Weimer wrote:
>
>> In any case, there's another reading of the UEFI Secure Boot
>> requirements: you may run any code you wish after calling
>> ExitBootServices().  That could be an unsigned, traditional GRUB.  But
>> this will not generally address the issue of dual-booting Windows 8 in
>> such a way that Windows sees that the device has enabled Microsoft
>> Secure Boot.
>
> Would it be possible to have a signed bootloader that allows booting
> Win8 from within the secure environment, or it could exit the secure
> environment and run unsigned grub?

On systems where the firmware supports multiple boot loaders, this
would work.

On systems which support just one boot loader, the next-stage boot
loader could be signed or not, it would not have access to the
privileged Secure Boot environment.  The decision to boot the
Secure-Boot-capable operating system would have to be made before
calling ExitBootServices(), otherwise that operating system will not
see Secure Boot support.

Re: [GIT PULL] Load keys from signed PE binaries

[Matthew Garrett]

On Thu, Feb 28, 2013 at 09:43:10AM -0600, Chris Friesen wrote:
> On 02/28/2013 01:57 AM, Florian Weimer wrote:
> 
> >In any case, there's another reading of the UEFI Secure Boot
> >requirements: you may run any code you wish after calling
> >ExitBootServices().  That could be an unsigned, traditional GRUB.  But
> >this will not generally address the issue of dual-booting Windows 8 in
> >such a way that Windows sees that the device has enabled Microsoft
> >Secure Boot.
> 
> Would it be possible to have a signed bootloader that allows booting
> Win8 from within the secure environment, or it could exit the secure
> environment and run unsigned grub?

What would stop the unsigned grub from installing a firmware hook that 
lies about whether or not Secure Boot is enabled, and then booting 
Windows?

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [GIT PULL] Load keys from signed PE binaries

[Florian Weimer]

* Matthew Garrett:

>> Would it be possible to have a signed bootloader that allows booting
>> Win8 from within the secure environment, or it could exit the secure
>> environment and run unsigned grub?
>
> What would stop the unsigned grub from installing a firmware hook that 
> lies about whether or not Secure Boot is enabled, and then booting 
> Windows?

Windows would not have access to the product key because it is stored
in a variable without EFI_VARIABLE_RUNTIME_ACCESS, so WGA and other
checks will fail, and the user will notice.

(Not sure if it is implemented this way, my test machine lost the
firmware-embedded product key after the mainboard was replaced.)

Re: [GIT PULL] Load keys from signed PE binaries

[Matthew Garrett]

On Thu, Feb 28, 2013 at 08:41:13PM +0100, Florian Weimer wrote:
> * Matthew Garrett:
> 
> >> Would it be possible to have a signed bootloader that allows booting
> >> Win8 from within the secure environment, or it could exit the secure
> >> environment and run unsigned grub?
> >
> > What would stop the unsigned grub from installing a firmware hook that 
> > lies about whether or not Secure Boot is enabled, and then booting 
> > Windows?
> 
> Windows would not have access to the product key because it is stored
> in a variable without EFI_VARIABLE_RUNTIME_ACCESS, so WGA and other
> checks will fail, and the user will notice.

grub's running before ExitBootServices(), because otherwise it has no 
way to actually read anything off disk. Or draw to the screen. Or 
receive keyboard input. So if it boots Windows, Windows is running in 
exactly the environment it would expect to be in.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [GIT PULL] Load keys from signed PE binaries

[Florian Weimer]

* Matthew Garrett:

> On Thu, Feb 28, 2013 at 08:41:13PM +0100, Florian Weimer wrote:
>> * Matthew Garrett:
>> 
>> >> Would it be possible to have a signed bootloader that allows booting
>> >> Win8 from within the secure environment, or it could exit the secure
>> >> environment and run unsigned grub?
>> >
>> > What would stop the unsigned grub from installing a firmware hook that 
>> > lies about whether or not Secure Boot is enabled, and then booting 
>> > Windows?
>> 
>> Windows would not have access to the product key because it is stored
>> in a variable without EFI_VARIABLE_RUNTIME_ACCESS, so WGA and other
>> checks will fail, and the user will notice.
>
> grub's running before ExitBootServices(), because otherwise it has no 
> way to actually read anything off disk. Or draw to the screen.

Sorry, if Linux can read from the disk after ExitBootServices(), so
can a boot loader.  Actually, we could boot Linux directly, with an
initrd which contains a boot selector, and use kexec if the chosen
kernel doesn't match the initial one.

Re: [GIT PULL] Load keys from signed PE binaries

[Matthew Garrett]

On Thu, Feb 28, 2013 at 09:23:45PM +0100, Florian Weimer wrote:
> * Matthew Garrett:
> > grub's running before ExitBootServices(), because otherwise it has no 
> > way to actually read anything off disk. Or draw to the screen.
> 
> Sorry, if Linux can read from the disk after ExitBootServices(), so
> can a boot loader.  Actually, we could boot Linux directly, with an
> initrd which contains a boot selector, and use kexec if the chosen
> kernel doesn't match the initial one.

"A bootloader" might be able to. grub can't.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [GIT PULL] Load keys from signed PE binaries

[Jiri Kosina]

On Thu, 21 Feb 2013, David Howells wrote:

> The way we have come up with to get around this is to embed an X.509
> certificate containing the key in a section called ".keylist" in an EFI PE
> binary and then get the binary signed by Microsoft.  The key can then be passed
> to the kernel by passing the signed binary:
> 
> 	keyctl padd asymmetric "" {ID of .system_keyring} <pekey.efi.signed

Please let me take this back to square one for a very short moment.


I completely fail to understand how your security model is dealing with 
this scenario:

- Mr. Evil Blackhat creates EFI PE binary from "int main() { return 42; }" 
  (psuedo)code
- Mr. Evil Blackhat puts his own key into .keylist section of this binary
- Mr. Evil Blackhat goes through the $99 process of having this binary 
  signed by Microsoft. They don't have a slightest reason not to sign it, 
  as the binary obviously can't be used to run backdoored Windows
- Mr. Evil Blackhat then uses keyctl to process this signed binary
- Mr. Evil Blackhat modprobes i_own_your_ring0.ko which is signed by 
  his key, and he instantly has his code running in your SecureBoot 
  environment


Let me formulate my point more clearly -- Microsoft very likely going to 
sign hello world EFI PE binary, no matter the contents of .keylist 
section, as they don't give a damn about this section, as it has zero 
semantic value to them, right?

They sign the binary. By signing the binary, they are *NOT* establishing 
cryptographic chain of trust to the key stored in .keylist, but your 
patchset seems to imply so.

What am I missing?

Thanks,

-- 
Jiri Kosina
SUSE Labs

Re: [GIT PULL] Load keys from signed PE binaries

[Matthew Garrett]

On Thu, Feb 28, 2013 at 11:48:06PM +0100, Jiri Kosina wrote:

> Let me formulate my point more clearly -- Microsoft very likely going to 
> sign hello world EFI PE binary, no matter the contents of .keylist 
> section, as they don't give a damn about this section, as it has zero 
> semantic value to them, right?
> 
> They sign the binary. By signing the binary, they are *NOT* establishing 
> cryptographic chain of trust to the key stored in .keylist, but your 
> patchset seems to imply so.

Mr Evil Blackhat's binary is then a mechanism for circumventing the 
Windows trust mechanism, and as such his account is subject to 
termination and his binary can be added to dbx. We'd check the binary 
hash against dbx and refuse to load it on systems that have received the 
update, and Mr Evil Blackhat would have to find a new bunch of identity 
documents to create a new account to repeat the process.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [GIT PULL] Load keys from signed PE binaries

[Jiri Kosina]

On Thu, 28 Feb 2013, Matthew Garrett wrote:

> > Let me formulate my point more clearly -- Microsoft very likely going to 
> > sign hello world EFI PE binary, no matter the contents of .keylist 
> > section, as they don't give a damn about this section, as it has zero 
> > semantic value to them, right?
> > 
> > They sign the binary. By signing the binary, they are *NOT* establishing 
> > cryptographic chain of trust to the key stored in .keylist, but your 
> > patchset seems to imply so.
> 
> Mr Evil Blackhat's binary is then a mechanism for circumventing the 
> Windows trust mechanism, 

Yes, the "hello world" one. 

But the real harm is being done by the i_own_your_ring0.ko module, which 
can be modprobed on all the systems where the signed "hello world" binary 
has been keyctl-ed before it was blacklisted.

In other words -- you blacklist the population of the key on systems by 
blakclisting the key-carrying binary, but the key remains trusted on 
whatever system the binary has been processed by keyctl before. Right?

If so, that's a clear difference from normal X.509 chain of trust (i.e. 
the difference between having the key signed, and having the binary 
signed).

-- 
Jiri Kosina
SUSE Labs

Re: [GIT PULL] Load keys from signed PE binaries

[Matthew Garrett]

On Fri, Mar 01, 2013 at 12:02:43AM +0100, Jiri Kosina wrote:

> But the real harm is being done by the i_own_your_ring0.ko module, which 
> can be modprobed on all the systems where the signed "hello world" binary 
> has been keyctl-ed before it was blacklisted.

Sure, if you've been infected before the revocation, you'll still be 
infected. There's not really any good way around that.

> In other words -- you blacklist the population of the key on systems by 
> blakclisting the key-carrying binary, but the key remains trusted on 
> whatever system the binary has been processed by keyctl before. Right?

You have to re-load it on every boot, it's not a permanent thing.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [GIT PULL] Load keys from signed PE binaries

[Jiri Kosina]

On Thu, 28 Feb 2013, Matthew Garrett wrote:

> > But the real harm is being done by the i_own_your_ring0.ko module, which 
> > can be modprobed on all the systems where the signed "hello world" binary 
> > has been keyctl-ed before it was blacklisted.
> 
> Sure, if you've been infected before the revocation, you'll still be 
> infected. There's not really any good way around that.

Which is a very substantial difference to normal X509 chain of trust, 
isn't it?

This security model seems to be quite seriously flawed to me (in a sense 
that it has nothing to do with chain of trust as mandated by X509 even 
though it tries to pretend the opposite)

And frankly, Linus' proposal at [1] doesn't really make it any better in 
principle, it just keeps the whole thing out of kernel.

[1] https://lkml.org/lkml/2013/2/21/228

> > In other words -- you blacklist the population of the key on systems by 
> > blakclisting the key-carrying binary, but the key remains trusted on 
> > whatever system the binary has been processed by keyctl before. Right?
> 
> You have to re-load it on every boot, it's not a permanent thing.

That unfortunately seems to be very weak security measure as well.

Thanks,

-- 
Jiri Kosina
SUSE Labs

Re: [GIT PULL] Load keys from signed PE binaries

[Matthew Garrett]

On Fri, Mar 01, 2013 at 12:45:23AM +0100, Jiri Kosina wrote:
> On Thu, 28 Feb 2013, Matthew Garrett wrote:
> > Sure, if you've been infected before the revocation, you'll still be 
> > infected. There's not really any good way around that.
> 
> Which is a very substantial difference to normal X509 chain of trust, 
> isn't it?

If you've loaded an x.509 certificate into the kernel and it's later 
revoked, any module signed with the key is going to be loadable until 
it's revoked. I don't see an especially large difference here?

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [GIT PULL] Load keys from signed PE binaries

[Jiri Kosina]

On Thu, 28 Feb 2013, Matthew Garrett wrote:

> > > Sure, if you've been infected before the revocation, you'll still be 
> > > infected. There's not really any good way around that.
> > 
> > Which is a very substantial difference to normal X509 chain of trust, 
> > isn't it?
> 
> If you've loaded an x.509 certificate into the kernel and it's later 
> revoked, any module signed with the key is going to be loadable until 
> it's revoked. I don't see an especially large difference here?

i_own_your_ring0.ko can be modprobed long after blacklisting of "hello 
world" binary hash has happened on the very particular machine in its dbx 
(as there is no link, in a x509-chain-of-trust-sense, between the hash of 
the PE binary and the i_own_your_ring0.ko signature key).

modprobe of a module signed by a key that has been blacklisted on the very 
particular machine in its dbx is not going to work (as there is a very 
direct x509 chain of trust link).

No?

Thanks,

-- 
Jiri Kosina
SUSE Labs

Re: [GIT PULL] Load keys from signed PE binaries

[Matthew Garrett]

On Fri, Mar 01, 2013 at 12:52:51AM +0100, Jiri Kosina wrote:
> On Thu, 28 Feb 2013, Matthew Garrett wrote:
> > If you've loaded an x.509 certificate into the kernel and it's later 
> > revoked, any module signed with the key is going to be loadable until 
> > it's revoked. I don't see an especially large difference here?
> 
> i_own_your_ring0.ko can be modprobed long after blacklisting of "hello 
> world" binary hash has happened on the very particular machine in its dbx 
> (as there is no link, in a x509-chain-of-trust-sense, between the hash of 
> the PE binary and the i_own_your_ring0.ko signature key).

Ah, I see what you mean. Yes, we should probably keep track of the 
linkage between the original hash and the key in the kernel and then 
invalidate the key if a corresponding dbx update is pushed, but it still 
seems likely that any attacker pushing the key onto your system would 
push the evil module simultaneously. The "I have an evil key but no evil 
module installed" case seems less likely.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [GIT PULL] Load keys from signed PE binaries

[Jiri Kosina]

On Fri, 1 Mar 2013, Matthew Garrett wrote:

> > > If you've loaded an x.509 certificate into the kernel and it's later 
> > > revoked, any module signed with the key is going to be loadable until 
> > > it's revoked. I don't see an especially large difference here?
> > 
> > i_own_your_ring0.ko can be modprobed long after blacklisting of "hello 
> > world" binary hash has happened on the very particular machine in its dbx 
> > (as there is no link, in a x509-chain-of-trust-sense, between the hash of 
> > the PE binary and the i_own_your_ring0.ko signature key).
> 
> Ah, I see what you mean. Yes, we should probably keep track of the 
> linkage between the original hash and the key in the kernel and then 
> invalidate the key if a corresponding dbx update is pushed, 

That will at least make the blacklisting work properly, yes.

It of course still doesn't fix the principal problem, that you are 
artificially changing the signature semantics of "Microsoft trusts this 
binary" to "we claim that Microsoft actually meant that they trust this 
key".
That has very little to do with proper X509 cryptography.

But at least we are on a same page now.

Thanks,

-- 
Jiri Kosina
SUSE Labs

Re: [GIT PULL] Load keys from signed PE binaries

[Vojtech Pavlik]

On Thu, Feb 28, 2013 at 10:51:15PM +0000, Matthew Garrett wrote:
> On Thu, Feb 28, 2013 at 11:48:06PM +0100, Jiri Kosina wrote:
> 
> > Let me formulate my point more clearly -- Microsoft very likely going to 
> > sign hello world EFI PE binary, no matter the contents of .keylist 
> > section, as they don't give a damn about this section, as it has zero 
> > semantic value to them, right?
> > 
> > They sign the binary. By signing the binary, they are *NOT* establishing 
> > cryptographic chain of trust to the key stored in .keylist, but your 
> > patchset seems to imply so.
> 
> Mr Evil Blackhat's binary is then a mechanism for circumventing the 
> Windows trust mechanism, and as such his account is subject to 
> termination and his binary can be added to dbx. 

Why?

Let's take a look on what would happen in this scenario:

A PE binary, from Mr. Blackhat, doing nothing, in general, but
containing a key in a section, was signed by MS on the grounds that the
binary isn't harmful.

By issuing the signature, MS is attesting that the binary is safe, but
isn't saying anything about the data (key) embedded in it. It doesn't
say the key comes from a trusted party. It just says "this isn't
malware", and that's what their tools verify.

Your shim loader (signed by MS) loads your Linux kernel.

Your Linux kernel, then, based on the key-in-PE model decides to trust
the key, although nobody really said it's to be trusted.

Mr. Blackhat then can load his i_own_your_ring0.ko module signed by his
key on your system, having obtained root access previously.

You call Microsoft, telling them what Mr. Blackhat has done.

They now can:

a) Do what you want: Disable Mr. Blackhat's account and revoke the hash
   of his binary.

But also:

b) Say, "oh well, we're sorry this kills your security model, but it's
enough for us that you already fully booted Linux to worry about Windows
security, this affects only your distribution and we don't care".

c) Decide your security model is flawed, because you're abusing their
signature process to mean something else from what they intended and
revoke your shim hash instead.

And I don't think you can rely on MS doing 'a'. Particularly when there
will be a large number of key-in-PE binaries signed by them at that
point, with them not being able to tell by any analysis which of them
are evil and which not.

I would even say b) is most likely.

> We'd check the binary hash against dbx and refuse to load it on
> systems that have received the update, and Mr Evil Blackhat would have
> to find a new bunch of identity documents to create a new account to
> repeat the process.

Yes, from the point it gets blacklisted, it's fairly clear. You're
forced to reboot, but under the Secure Boot model, you have to do that
on any system that used code whose hash has been revoked.

-- 
Vojtech Pavlik
Director SuSE Labs

Re: [GIT PULL] Load keys from signed PE binaries

[Theodore Ts'o]

On Fri, Mar 01, 2013 at 11:00:52AM +0100, Vojtech Pavlik wrote:
> 
> Mr. Blackhat then can load his i_own_your_ring0.ko module signed by his
> key on your system, having obtained root access previously.

The question will be what does Mr. Blackhat do with this
i_own_your_ring0.ko module.  The FUD that has been flung about is that
it would be possible for Mr. Blackhat to create a small, tight
partition containing a signed Linux kernel (from Red Hat or SuSE,
doesn't reallly matter), and enough of a initrd which would include
said i_own_your_ring0.ko module.  This would then be used in a bootkit
that would boot Linux and get ring0 access, and then use that to
create malware that would be used to infect Windows systems in a way
that wouldn't be detected by users.

It would essentially be the same as the bootsector virus, except it
would take 2 or 3 orders of magnitude more disk space, and probably
add one or two orders of magnitude more time to the boot time.
Whether this could be done in an undetectable fashion is an
interesting question, but the assertion is that it can be done, and so
we need to pour all sorts of unspeaking gunk into the kernel and
disable Systemtap to prevent this from happening.

> You call Microsoft, telling them what Mr. Blackhat has done.
> 
> They now can:
> 
> a) Do what you want: Disable Mr. Blackhat's account and revoke the hash
>    of his binary.
> 
> But also:
> 
> b) Say, "oh well, we're sorry this kills your security model, but it's
> enough for us that you already fully booted Linux to worry about Windows
> security, this affects only your distribution and we don't care".
> 
> c) Decide your security model is flawed, because you're abusing their
> signature process to mean something else from what they intended and
> revoke your shim hash instead.

Well, if this is being used to attack Windows machines (assuming that
it is possible to create a bootkit using a Linux kernel, and initrd,
and the signed i_pown_your_ring0.ko odule), it's unlikely that (b)
would be a likely outcome.

Both (a) and (c) would solve Microsoft's security problem.  They could
do (c), but that would result in the PR and Legal morass resulting
from the accusatoin that they are abusing their monopoly position.
I'm not an expert in how much backbone the European anti-trust folks
have, so I can't really comment on how likely they would pursue this,
or whether they would be successful in the end, but more importantly,
I suspect Microsoft wouldn't be sure either.

						- Ted

Re: [GIT PULL] Load keys from signed PE binaries

[Matthew Garrett]

On Wed, Feb 27, 2013 at 08:35:45PM +0000, ownssh wrote:
> Matthew Garrett <mjg59 <at> srcf.ucam.org> writes:
> 
> > There's no way to update the UEFI key database without the update being 
> > signed by an already trusted key, so what you're proposing isn't 
> > possible.
> > 
> 
> I confused.
> Isn't custom mode can add user's own key?

Yes, but that involves physically-present end-user interaction. A 
bootloader can't do it even if it's signed by Microsoft.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [GIT PULL] Load keys from signed PE binaries

[Gene Heskett]

On Friday 01 March 2013, Matthew Garrett wrote:
>On Wed, Feb 27, 2013 at 08:35:45PM +0000, ownssh wrote:
>> Matthew Garrett <mjg59 <at> srcf.ucam.org> writes:
>> > There's no way to update the UEFI key database without the update
>> > being signed by an already trusted key, so what you're proposing
>> > isn't possible.
>> 
>> I confused.
>> Isn't custom mode can add user's own key?
>
>Yes, but that involves physically-present end-user interaction. A
>bootloader can't do it even if it's signed by Microsoft.

Thats a false flag Matthew.  We have been 'touch'ing a file to trigger an 
action on reboot, then typing "reboot" from 2000 miles away for at least a 
decade.  I fail to see why that idea couldn't be expanded to do this too.

Cheers, Gene
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
My web page: <http://coyoteden.dyndns-free.com:85/gene> is up!
My views 
<http://www.armchairpatriot.com/What%20Has%20America%20Become.shtml>
Friends may come and go, but enemies accumulate.
		-- Thomas Jones
I was taught to respect my elders, but its getting 
harder and harder to find any...

Re: [GIT PULL] Load keys from signed PE binaries

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1443 bytes --]

Hi Linus,

On Thu, 21 Feb 2013 10:56:44 -0800 Linus Torvalds <torvalds@linux-foundation.org> wrote:
>
> On Thu, Feb 21, 2013 at 10:34 AM, Peter Jones <pjones@redhat.com> wrote:
> > On Thu, Feb 21, 2013 at 10:25:47AM -0800, Linus Torvalds wrote:
> >>  - why do you bother with the MS keysigning of Linux kernel modules to
> >> begin with?
> >
> > This is not actually what the patchset implements.  All it's done here
> > is using PE files as envelopes for keys.  The usage this enables is to
> > allow for whoever makes a module (binary only or merely out of tree for
> > whatever reason) to sign it and vouch for it themselves.  That could
> > include, for example, a systemtap module.
> 
> Umm. And which part of "We already support that, using standard X.509
> certificates" did we suddenly miss?
> 
> So no. The PE file thing makes no sense what-so-ever. What you mention
> we can already do, and we already do it *better*.

So, is this enough close enough to "I will never take this" for me to
remove it from linux-next, or could further discussion persuade you?

David, if I do remove it, are there other patches in your pekey tree that
are still going forward?

I ask because the pekey tree is interacting with other trees and it does
not make sense to have those interactions in linux-next if the pekey work
is never going upstream.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: [GIT PULL] Load keys from signed PE binaries

[David Howells]

Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> David, if I do remove it, are there other patches in your pekey tree that
> are still going forward?

No.

David

Re: [GIT PULL] Load keys from signed PE binaries

[David Howells]

David Howells <dhowells@redhat.com> wrote:

> Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> 
> > David, if I do remove it, are there other patches in your pekey tree that
> > are still going forward?
> 
> No.

Well, maybe.  But feel free to drop it anyway for the moment.

David

Re: [GIT PULL] Load keys from signed PE binaries

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 566 bytes --]

Hi David,

On Wed, 20 Mar 2013 16:52:39 +0000 David Howells <dhowells@redhat.com> wrote:
>
> David Howells <dhowells@redhat.com> wrote:
> 
> > Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > 
> > > David, if I do remove it, are there other patches in your pekey tree that
> > > are still going forward?
> > 
> > No.
> 
> Well, maybe.  But feel free to drop it anyway for the moment.

OK, I have removed it for now, thanks.  Feel free to resubmit it if you
persuade Linus.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]