linux-kernel - Re: Trusted kernel patchset for Secure Boot lockdown

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1394834193.1286.11.camel@x230>
Date:	Fri, 14 Mar 2014 21:56:33 +0000
From:	Matthew Garrett <matthew.garrett@...ula.com>
To:	"gnomes@...rguk.ukuu.org.uk" <gnomes@...rguk.ukuu.org.uk>
CC:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"jmorris@...ei.org" <jmorris@...ei.org>,
	"keescook@...omium.org" <keescook@...omium.org>,
	"linux-security-module@...r.kernel.org" 
	<linux-security-module@...r.kernel.org>,
	"akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
	"hpa@...or.com" <hpa@...or.com>,
	"jwboyer@...oraproject.org" <jwboyer@...oraproject.org>,
	"linux-efi@...r.kernel.org" <linux-efi@...r.kernel.org>,
	"gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>
Subject: Re: Trusted kernel patchset for Secure Boot lockdown

On Fri, 2014-03-14 at 21:48 +0000, One Thousand Gnomes wrote:

> In your particularly implementation maybe you've got a weak setup where
> you don't measure down to your initrd. That's a *flaw* in your
> implementation. Don't inflict your limitations on others or on the
> future. EFI is only one (and not a very strong one at that) implementation
> of a 'secure' boot chain. A lot of other systems can not only propogate
> measurement and security assertions into their initrd they can propogate
> them into their rootfs (yes upgrades are .. exciting, but these kinds of
> users will live with that pain).

Signed userspace is not a requirement, and therefore any solution that
relies on a signed initrd is inadequate. There are use cases that
require verification of the initrd and other levels. This isn't one of
them.

> Even in EFI you can make your kernel or loader check the initrd signature
> and the rootfs signature if you want.

Except the initramfs gets built at kernel install time.
 
> > The fact that you keep saying measured really does make me suspect that
> > you misunderstand the problem. There's no measurement involved, there's
> > simply an assertion that the firmware (which you're forced to trust)
> > chose, via some policy you may be unaware of, to trust the booted
> > kernel.
> 
> You are currently using some of those interfaces for measuring to produce
> a notionally 'trusted' initial loaded environment.
> 
> Correct me if I am wrong but your starting point is "I have a chain of
> measurement as far as the kernel I load". Without that I can just go into
> grub and 0wn you.

In my use case. But not all implementations will be measuring things -
they can assert that the kernel is trustworthy through some other
mechanism. This genuinely is about trust, not measurement.

-- 
Matthew Garrett <matthew.garrett@...ula.com>