From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756211AbaCNWcJ (ORCPT ); Fri, 14 Mar 2014 18:32:09 -0400 Received: from lxorguk.ukuu.org.uk ([81.2.110.251]:37059 "EHLO lxorguk.ukuu.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754419AbaCNWcG (ORCPT ); Fri, 14 Mar 2014 18:32:06 -0400 Date: Fri, 14 Mar 2014 22:31:50 +0000 From: One Thousand Gnomes To: Matthew Garrett Cc: "linux-kernel@vger.kernel.org" , "jmorris@namei.org" , "keescook@chromium.org" , "linux-security-module@vger.kernel.org" , "akpm@linux-foundation.org" , "hpa@zytor.com" , "jwboyer@fedoraproject.org" , "linux-efi@vger.kernel.org" , "gregkh@linuxfoundation.org" Subject: Re: Trusted kernel patchset for Secure Boot lockdown Message-ID: <20140314223150.0b49723e@alan.etchedpixels.co.uk> In-Reply-To: <1394835345.1286.22.camel@x230> References: <1393445473-15068-1-git-send-email-matthew.garrett@nebula.com> <1394686919.25122.2.camel@x230> <1394726363.25122.16.camel@x230> <20140313212450.67f1de8e@alan.etchedpixels.co.uk> <1394746248.27846.3.camel@x230> <20140313232140.03bdaac3@alan.etchedpixels.co.uk> <1394762250.6416.24.camel@x230.lan> <20140314122231.17b9ca8a@alan.etchedpixels.co.uk> <1394801518.6416.38.camel@x230.lan> <20140314170655.0ce398a3@alan.etchedpixels.co.uk> <1394820664.26846.18.camel@x230.mview.int.nebula.com> <20140314214806.54a3d031@alan.etchedpixels.co.uk> <1394834193.1286.11.camel@x230> <20140314220840.29a12171@alan.etchedpixels.co.uk> <1394835345.1286.22.camel@x230> Organization: Intel Corporation X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.20; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 14 Mar 2014 22:15:45 +0000 Matthew Garrett 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 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) And it attests the trustworthiness of the filesystem by measuring it. If you have a measurement of object X that states it is unchanged then you have a valid measurement of any subset of object X for which the same assertion is proven. In this case since you know all the bits in the root fs are as before, so you know all the bits in the module are as before And how do you know all the bits in the root fs are as before, because you have a set of measurements (hashes) on partition 12. At the end of the day you end up with a chain of measurements from a trusted thing you deep immutable. If your chain has gaps you have holes (see above). So ChromeOS loads *measured* kernel modules. It just did the measuring differently to the signed module code. Alan From mboxrd@z Thu Jan 1 00:00:00 1970 From: One Thousand Gnomes Subject: Re: Trusted kernel patchset for Secure Boot lockdown Date: Fri, 14 Mar 2014 22:31:50 +0000 Message-ID: <20140314223150.0b49723e@alan.etchedpixels.co.uk> References: <1393445473-15068-1-git-send-email-matthew.garrett@nebula.com> <1394686919.25122.2.camel@x230> <1394726363.25122.16.camel@x230> <20140313212450.67f1de8e@alan.etchedpixels.co.uk> <1394746248.27846.3.camel@x230> <20140313232140.03bdaac3@alan.etchedpixels.co.uk> <1394762250.6416.24.camel@x230.lan> <20140314122231.17b9ca8a@alan.etchedpixels.co.uk> <1394801518.6416.38.camel@x230.lan> <20140314170655.0ce398a3@alan.etchedpixels.co.uk> <1394820664.26846.18.camel@x230.mview.int.nebula.com> <20140314214806.54a3d031@alan.etchedpixels.co.uk> <1394834193.1286.11.camel@x230> <20140314220840.29a12171@alan.etchedpixels.co.uk> <1394835345.1286.22.camel@x230> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1394835345.1286.22.camel@x230> Sender: linux-efi-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Matthew Garrett Cc: "linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , "jmorris-gx6/JNMH7DfYtjvyW6yDsg@public.gmane.org" , "keescook-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org" , "linux-security-module-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , "akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org" , "hpa-YMNOUZJC4hwAvxtiuMwx3w@public.gmane.org" , "jwboyer-rxtnV0ftBwyoClj4AeEUq9i2O/JbrIOy@public.gmane.org" , "linux-efi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , "gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org" List-Id: linux-efi@vger.kernel.org On Fri, 14 Mar 2014 22:15:45 +0000 Matthew Garrett 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 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) And it attests the trustworthiness of the filesystem by measuring it. If you have a measurement of object X that states it is unchanged then you have a valid measurement of any subset of object X for which the same assertion is proven. In this case since you know all the bits in the root fs are as before, so you know all the bits in the module are as before And how do you know all the bits in the root fs are as before, because you have a set of measurements (hashes) on partition 12. At the end of the day you end up with a chain of measurements from a trusted thing you deep immutable. If your chain has gaps you have holes (see above). So ChromeOS loads *measured* kernel modules. It just did the measuring differently to the signed module code. Alan