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: <87hap3s3yl.fsf@xmission.com>
Date:	Mon, 05 Nov 2012 21:19:46 -0800
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Matthew Garrett <mjg59@...f.ucam.org>
Cc:	"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

Matthew Garrett <mjg59@...f.ucam.org> writes:

> On Mon, Nov 05, 2012 at 07:36:32PM -0800, Eric W. Biederman wrote:
>
>> For automated installs you don't have to satisfy me.  Feel free to
>> deliver a lousy solution to your users.   Just don't use your arbitrary
>> design decisions to justify your kernel patches.
>
> My kernel patches are justified by genuine user requirements. 

Hogwash.

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.

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.

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.

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.

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.

> If you 
> don't feel that there's any requirement for the kernel to satisfy the 
> people who use it, you're free to ignore those patches.

I feel allowing the kernel to be hacked to bits and decend into an
unmaintainable mess does not serve the users who use the kernel,
and to prevent that technically poor patches should be rejected.

This helps prevent non-technical considerations from justifying
technically poor decisions.

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