Message-ID: <87bob6pxtl.fsf@mid.deneb.enyo.de>
Date:	Tue, 26 Feb 2013 22:30:46 +0100
From:	Florian Weimer <fw@...eb.enyo.de>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Matthew Garrett <mjg59@...f.ucam.org>,
	"Theodore Ts'o" <tytso@....edu>,
	Greg KH <gregkh@...uxfoundation.org>,
	David Howells <dhowells@...hat.com>,
	Josh Boyer <jwboyer@...hat.com>,
	Peter Jones <pjones@...hat.com>,
	Vivek Goyal <vgoyal@...hat.com>,
	Kees Cook <keescook@...omium.org>, keyrings@...ux-nfs.org,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [GIT PULL] Load keys from signed PE binaries

* Linus Torvalds:

> So here's what I would suggest, and it is based on REAL SECURITY and
> on PUTTING THE USER FIRST instead of your continual "let's please
> microsoft by doing idiotic crap" approach.

I think the real question is this one: Is there *any* device out there
which comes with Microsoft Secure Boot enabled, but doesn't have a
copy of Windows 8 on it?

I guess there isn't.  So Secure Boot support is only required for
supporting dual-booting Windows 8, while still retaining the automated
recovery capabilities (which might well remove the Linux installation
on the same box).

Without dual-booting, there is currently no reason whatsoever to
enable UEFI Secure Boot (or the Microsoft variant).  Not providing a
signed boot loader forces the user to configure the device in a way
that ensures long-term supportability and feature stability (i.e.,
they don't suffer when someone decides to introduce further
restrictions under CAP_COMPROMISE_KERNEL).

Unfortuantely, almost all people I talked to *want* secure boot,
presumably because security is good.  Many of them hate the Microsoft
key (but wouldn't want to own the key, either), but the proposed
alternatives, such as distro-specific keys, are impractical.  Do we
really want systems on which you cannot install Fedora once you have
installed Debian?

> So instead of pleasing microsoft, try to see how we can add real security:
>
>  - a distro should sign its own modules AND NOTHING ELSE by default.

I strongly agree with that (but obviously not the wording, *ahem*).
Actually, we already sign our own kernel modules (and all the software
we ship) in one way or the other.  Some of us even sign a lot of
third-party software which we haven't built from source.

>  - before loading any third-party module, you'd better make sure you
> ask the user for permission. On the console. Not using keys. Nothing
> like that. Keys will be compromised. Try to limit the damage, but more
> importantly, let the user be in control.

This needs a trusted input/output path to the user.  Currently, this
seems difficult to provide once arbitrary userspace code has run as
root.  Hence the round-trip through the UEFI pre-boot environment.

One thing that would be neat is an assurance that if you boot some
image over PXE, it doesn't do any harm to your system.  This isn't
something Microsoft Secure Boot promises at the moment because a
signed boot loader can easily lead to an initrd which wipes your hard
disk.  It's really hard to get there, but at least it would be
something useful.  Similarly, server firmware in a datacenter could
validate the recovery image before executing.  (Actually, I view boot
path validation mainly as a server technology—for clients, you just
save $1 for the known-good, read-only recovery medium.)
--
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