Re: [Ksummit-discuss] [TOPIC] Secure/verified boot and roots of trust

[Andy Lutomirski <luto@amacapital.net>]

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

On Aug 2, 2016 9:42 PM, "Michael S. Tsirkin" <mst@redhat.com> wrote:
>
> On Tue, Aug 02, 2016 at 09:34:14PM -0700, Andy Lutomirski wrote:
> > On Tue, Aug 2, 2016 at 8:32 PM, Matthew Garrett <mjg59@coreos.com>
wrote:
> > > On Tue, Aug 2, 2016 at 7:58 PM, Andy Lutomirski <luto@amacapital.net>
wrote:
> > >>  - Appeasing the Secure Boot deities.  AFAIK this specifically
> > >> requires that we verify the kernel and its modules using a
combination
> > >> of EFI-supplied and distro keys.
> > >
> > > Eh not quite. The rules are basically that if a Microsoft-signed
> > > object can be used to compromise other operating systems, Microsoft
> > > may unilaterally blacklist that object. Allowing arbitrary module
> > > loading or arbitrary kexec clearly makes it straightforward to simply
> > > use a signed Linux boot chain to then boot a compromised version of
> > > any other operating system, defeating the point of Secure Boot.
> >
> > > Distro
> > > keys are used for module signing because that's the easiest way to
> > > handle it (sign them during build and then discard the key),
> >
> > With my module hashing patches, that'll be even simpler.  The kernel
> > image will contain a list of SHA256 hashes of in-tree .ko files and
> > will accept those files.
>
> Hmm. I kind of like ability to build and add modules to a running
> kernel. And I think some distros might use it too, updating modules
> without updating the kernel (doesn't work if you discard the key,
> obviously).

I have no plans to prevent the existing module signature verification
scheme from working.  I just see no reason that in-tree modules should need
to be signed.

>
> > > UEFI keys
> > > are used to appease some manufacturers (they can ship their
> > > binary-only drivers signed with a key that's in firmware) and shim
> > > keys are used to allow users to sign their own modules.
> >
> > Hmm.  Would it be okay if a physically present user could subvert it?
> > For example, if a physically present user typed "insecure" into a
> > bootloader command line and thus turned off signature verification?
>
> Typically already possible with firmware menus.

Sure, but I'm trying to understand what types of attacks we need to resist.

[-- Attachment #2: Type: text/html, Size: 2929 bytes --]