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]

Date:	Tue, 06 Nov 2012 08:56:01 +0100
From:	Florian Weimer <fw@...eb.enyo.de>
To:	ebiederm@...ssion.com (Eric W. Biederman)
Cc:	Matthew Garrett <mjg59@...f.ucam.org>,
	"H. Peter Anvin" <hpa@...or.com>,
	James Bottomley <James.Bottomley@...senPartnership.com>,
	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

* Eric W. Biederman:

> If windows is not present on a system linux can not be used to boot a
> compromised version of windows without user knowledge because windows is
> not present.

Interesting idea.  Unfortunately, it is very hard to detect reliably
that Windows is not present from the bootloader, so it's not possible
to use this approach to simplify matters.

> If windows is present on a system then to install linux a user must be
> present and push buttons to get the system to boot off of install media.

That's not necessarily true.

> If a user is present a user presence test may be used to prevent a
> bootloader signed with  Microsoft's key from booting linux without the
> users consent, and thus prevent Linux from attacking windows users.

As already explained, I don't think that user presence accomplishes
anything.  You need informed consent, and it's impossible to cram that
on a 80x25 screen.  You also need to make sure that you aren't
unnecessarily alarmist.  We don't want a "Linux may harm your
computer" warning.

> Therefore preventing the revokation of a signature with Microsoft's
> signature from your bootloader does not justify elaborate kernel
> modifications to prevent the booting a compromised version of windows.

I don't like this approach, either.

> Furthermore no matter how hard we try with current techniques there will
> eventually be kernel bugs that allow attackers to inject code into the
> kernel.  So attempting to fully close that attack vector is
> questionable.

I suspect we'd need to revoke old binaries after a grace period.  I
guess the Microsoft approach is to revoke only what's actually used
for attacks, but that leads to a lot of unpredictability for our
users.

It's also annoying if we figure out after release that we have to
disable additional kernel functionality because it can be used to
compromise the boot path.  Users will not like that, especially if
they do not use Windows at all.

Personally, I think the only way out of this mess is to teach users
how to disable Secure Boot.
--
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/