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: <CAGXu5j+3vVKhFPOsArYddA+QqhvVUunj8eYOF799rDv=3MGtyg@mail.gmail.com>
Date:	Fri, 14 Mar 2014 08:54:23 -0700
From:	Kees Cook <keescook@...omium.org>
To:	Matthew Garrett <matthew.garrett@...ula.com>
Cc:	"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>,
	"gnomes@...rguk.ukuu.org.uk" <gnomes@...rguk.ukuu.org.uk>,
	"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 8:46 AM, Matthew Garrett
<matthew.garrett@...ula.com> wrote:
> On Fri, 2014-03-14 at 08:23 -0700, Kees Cook wrote:
>
>> The command line problem here is a total red herring. If you've got a
>> measured kernel, you have a measured command line. (If not, you don't
>> have a measured kernel.) Dealing with the command line has nothing to
>> do with enforcing the ring0/uid0 boundary which is what this patch
>> series does.
>
> That's why I used trusted rather than measured. The Secure Boot trust
> model assumes that the user is able to modify the command line (it's
> basically impossible to deploy generically otherwise), so we need to
> filter out command line options that allow a user to elevate themselves
> into the kernel at boot time.

All the more reason to ignore command line at this point. For Chrome
OS, it's part of our boot state, so we don't care about it. For
generic Secure Boot, we can add checks for dangerous stuff as we go
forward. That's why I like this interface -- we can add to it as we
identify bad stuff, and it stay separate from other semantics.

-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/