linux-kernel - Re: [RFC 1/1] ima: digital signature verification using asymmetric keys

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, 30 Jan 2013 06:32:05 +0000
From:	Matthew Garrett <mjg59@...f.ucam.org>
To:	Vivek Goyal <vgoyal@...hat.com>
Cc:	Mimi Zohar <zohar@...ux.vnet.ibm.com>,
	"Kasatkin, Dmitry" <dmitry.kasatkin@...el.com>,
	dhowells@...hat.com, jmorris@...ei.org,
	linux-security-module@...r.kernel.org,
	linux-crypto@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC 1/1] ima: digital signature verification using asymmetric
 keys

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@...f.ucam.org
--
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/