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: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1351875164.2439.42.camel@dabdike.int.hansenpartnership.com>
Date:	Fri, 02 Nov 2012 16:52:44 +0000
From:	James Bottomley <James.Bottomley@...senPartnership.com>
To:	Pavel Machek <pavel@....cz>
Cc:	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>,
	Matthew Garrett <mjg59@...f.ucam.org>,
	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 Fri, 2012-11-02 at 17:33 +0100, Pavel Machek wrote:
> On Thu 2012-11-01 15:02:25, Chris Friesen wrote:
> > On 11/01/2012 02:27 PM, Pavel Machek wrote:
> > 
> > >Could someone write down exact requirements for Linux kernel to be signed by Microsoft?
> > >Because thats apparently what you want, and I don't think crippling kexec/suspend is
> > >enough.
> > 
> > As I understand it, the kernel won't be signed by Microsoft.
> 
> > Rather, the bootloader will be signed by Microsoft and the vendors
> > will be the ones that refuse to sign a kernel unless it is
> > reasonably assured that it won't be used as an attack vector.
> 
> Yes. So can someone write down what "used as an attack vector" means?
> 
> Because, AFAICT, Linux kernel is _designed_ to work as an attact
> vector. We intentionally support wine, and want to keep that support.

I think there's a variety of opinions on this one.

My definition is that you can construct a signed boot system from the
components delivered with a Linux distribution that will fairly
invisibly chain load a hacked version of windows.  Thus allowing the
windows user to think they have a chain of trust to the UEFI firmware
when, in fact, they haven't.

The first question is how many compromises do you need.  Without
co-operation from windows, you don't get to install something in the
boot system, so if you're looking for a single compromise vector, the
only realistic attack is to trick the user into booting a hacked linux
system from USB or DVD.

There's also a lot of debate around "fairly invisibly".  If your hack
involves shim->grub->linux->windows, that's a fairly long boot process
with time for the user to notice something.

Obviously, a boot loader that breaks the trust chain is ideal as a
windows attack vector, which is why most pre bootloaders on virgin
systems do a present user test (tell the user what they're doing and ask
permission to continue).  I really think that if the shim+MOK system
always paused and asked to continue if the MOK Boot Services variables
aren't present (i.e. it's a first boot virgin system), we've solved the
windows attack vector problem, and we can move on from this rather
sterile debate to think of how we can use secure boot to enhance Linux
security for the machine owner.

James

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