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]

Date:	Wed, 19 Mar 2014 12:50:41 -0700
From:	Kees Cook <keescook@...omium.org>
To:	One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>
Cc:	Matthew Garrett <matthew.garrett@...ula.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"jmorris@...ei.org" <jmorris@...ei.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, Mar 14, 2014 at 3:31 PM, One Thousand Gnomes
<gnomes@...rguk.ukuu.org.uk> wrote:
> On Fri, 14 Mar 2014 22:15:45 +0000
> Matthew Garrett <matthew.garrett@...ula.com> wrote:
>
>> On Fri, 2014-03-14 at 22:08 +0000, One Thousand Gnomes wrote:
>> > On Fri, 14 Mar 2014 21:56:33 +0000
>> > Matthew Garrett <matthew.garrett@...ula.com> wrote:
>> > > 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.
>> >
>> > The job of the kernel is to solve the general problem. There are lots of
>> > people who happen to care about verification beyond the kernel so it
>> > shouldn't be ignored. And they can do do things like load trusted SELinux
>> > rulesets even if you can't support it in your environment.
>>
>> The general problem includes having to support this even without an
>> selinux policy.
>
> Yes. No dispute about that. But equally the general solution should allow
> for it.
>
>> And one that's not going to change, so the general problem includes not
>> relying on a signed initramfs.
>
> Likewise
>
>> some other way. ChromeOS will load unmeasured kernel modules provided it
>> can attest to the trustworthyness of the filesystem containing them.
>
> See "How to Bypass Verified Boot Security in Chromium OS" 8)

That method a) is intentionally available (system owner can disable
firmware RO and install their own keys), and b) requires physical
presence.

> So ChromeOS loads *measured* kernel modules. It just did the measuring
> differently to the signed module code.

Right, using dm-verity. However, the read-only media case is still
valid (and is why I am still trying to get the module restrictions LSM
accepted, and why I'm modelling my firmware restrictions on the same
principle).

-Kees

-- 
Kees Cook
Chrome OS Security
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/