linux-kernel - Re: [RFC] Second attempt at kernel secure boot support

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]

Date:	Tue, 06 Nov 2012 22:51:59 +0100
From:	Florian Weimer <fw@...eb.enyo.de>
To:	Chris Friesen <chris.friesen@...band.com>
Cc:	"Eric W. Biederman" <ebiederm@...ssion.com>,
	Matthew Garrett <mjg59@...f.ucam.org>,
	"H. Peter Anvin" <hpa@...or.com>,
	James Bottomley <James.Bottomley@...senPartnership.com>,
	Pavel Machek <pavel@....cz>,
	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

* Chris Friesen:

> On 11/06/2012 01:56 AM, Florian Weimer wrote:
>
>> Personally, I think the only way out of this mess is to teach users
>> how to disable Secure Boot.
>
> If you're going to go that far, why not just get them to install a
> RedHat (or SuSE, or Ubuntu, or whoever) key and use that instead?

Behind that key, considerable infrastructure is needed, and the
challenges are not purely technical.  I don't expect many such keys as
a result.

> Secure boot does arguably solve a class of problems, so it seems a bit
> odd to recommend just throwing it out entirely.

I have never seen a Linux system with a compromised boot path.  Surely
they exist out there, but they are rare.  It's also relatively simple
to detect such a compromise on disk, from the outside.  Secure Boot
doesn't even allow you to safely boot from PXE because Fedora's shim
will automatically load an initrd which wipes all your disks.  (Safe
booting from network would be a compelling feature, but it's not in
the focus of Secure Boot; that's client-only technology at the
moment.)

Some side effects, such as the end of proprietary kernel modules, may
be desirable.  But others are not, like missing hibernate support (or
perhaps even X).
--
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/