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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20121104135251.GA17894@srcf.ucam.org>
Date:	Sun, 4 Nov 2012 13:52:51 +0000
From:	Matthew Garrett <mjg59@...f.ucam.org>
To:	James Bottomley <James.Bottomley@...senPartnership.com>
Cc:	Pavel Machek <pavel@....cz>,
	Chris Friesen <chris.friesen@...band.com>,
	Eric Paris <eparis@...isplace.org>,
	Jiri Kosina <jkosina@...e.cz>, Oliver Neukum <oneukum@...e.de>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Josh Boyer <jwboyer@...il.com>, linux-kernel@...r.kernel.org,
	linux-security-module@...r.kernel.org, linux-efi@...r.kernel.org
Subject: Re: [RFC] Second attempt at kernel secure boot support

On Sun, Nov 04, 2012 at 09:14:47AM +0000, James Bottomley wrote:

> I've actually had more than enough experience with automated installs
> over my career: they're either done by paying someone or using a
> provisioning system.  In either case, they provision a static image and
> boot environment description, including EFI boot services variables, so
> you can provision a default MOK database if you want the ignition image
> not to pause on firstboot.

And now you've moved the attack vector to a copy of your provisioning 
system instead.

> There is obviously the question of making the provisioning systems
> secure, but it's a separate one from making boot secure.

You don't get to punt on making the kernel secure by simply asserting 
that some other system can be secure instead. The chain of trust needs 
to go all the way back - if your security model is based on all installs 
needing a physically present end user, all installs need a physically 
present end user. That's not acceptable, so we need a different security 
model.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ