From: Matthew Garrett Subject: Re: [RFC 1/1] ima: digital signature verification using asymmetric keys Date: Wed, 30 Jan 2013 06:32:05 +0000 Message-ID: <20130130063205.GA15032@srcf.ucam.org> References: <20130125210157.GA13152@redhat.com> <20130128151527.GA5868@redhat.com> <20130128185625.GC5868@redhat.com> <1359404149.3906.75.camel@falcor1> <20130128202241.GB14405@redhat.com> <1359424135.3906.247.camel@falcor1> <20130129165853.GC21930@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Mimi Zohar , "Kasatkin, Dmitry" , dhowells@redhat.com, jmorris@namei.org, linux-security-module@vger.kernel.org, linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org To: Vivek Goyal Return-path: Content-Disposition: inline In-Reply-To: <20130129165853.GC21930@redhat.com> Sender: linux-security-module-owner@vger.kernel.org List-Id: linux-crypto.vger.kernel.org On Tue, Jan 29, 2013 at 11:58:53AM -0500, Vivek Goyal wrote: > On Mon, Jan 28, 2013 at 08:48:55PM -0500, Mimi Zohar wrote: > > The assumption has always been that the initramfs would be measured, for > > trusted boot, and appraised, for secure boot, before being executed. > > Hi Mimi, > > Ok. So for trusted boot, if initramfs is changed it will be detected. For > secureboot, atleast right now initramfs is not signed and appraised. But > I guess it could be added. > > But initramfs is generated by installer and installer does not have > private keys to sign it. So distributions could not sign initramfs. Right, there's a whole range of problems here. The first is that the initramfs has to contain the full set of drivers required to boot a given piece of hardware, and the precise set required varies between machines. Building a truly generic initramfs would result in significantly larger images. There's also an existing expectation that it be possible to break into initramfs execution for debugging purposes. Even ignoring that, most initramfs implementations aren't expected to be hardened against a user inserting shell control characters into the kernel command line. It would require significant engineering work to ensure that there's no way for an attacker to cause code execution before the key store has been locked. Shipping prebuilt initramfses is also difficult from a release engineering perspective. You'd need to keep track of the software versions that were included in the initramfs and ensure that the initramfs is rebuilt if any of those pieces of software are updated between the initramfs being generated and the software being shipped. Version skew could cause subtle bugs and also makes license compliance difficult. Finally, portions of the userspace in initramfs may be under licenses that require it to be possible for the end user to replace components. This isn't a problem as long as the keys in MOK can be used. There's additional small problems, like the initramfs containing the bootsplash theme and users expecting to be able to change that without having to generate crypto keys, but that's probably not a showstopper. But realistically, the first three problems make it unlikely that most distributions will be willing to depend on or ship pre-built initramfs images. -- Matthew Garrett | mjg59@srcf.ucam.org