[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1394811997.26846.2.camel@x230.mview.int.nebula.com>
Date: Fri, 14 Mar 2014 15:46:37 +0000
From: Matthew Garrett <matthew.garrett@...ula.com>
To: "keescook@...omium.org" <keescook@...omium.org>
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, 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.
--
Matthew Garrett <matthew.garrett@...ula.com>
Powered by blists - more mailing lists