linux-kernel - Re: [PATCH] x86: Lock down MSR writing in secure boot

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: <1360355671.18083.18.camel@x230.lan>
Date:	Fri, 8 Feb 2013 20:34:31 +0000
From:	Matthew Garrett <matthew.garrett@...ula.com>
To:	Kees Cook <keescook@...omium.org>
CC:	"H. Peter Anvin" <hpa@...or.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>,
	"x86@...nel.org" <x86@...nel.org>,
	"linux-efi@...r.kernel.org" <linux-efi@...r.kernel.org>,
	linux-security-module <linux-security-module@...r.kernel.org>
Subject: Re: [PATCH] x86: Lock down MSR writing in secure boot

On Fri, 2013-02-08 at 12:28 -0800, Kees Cook wrote:

> Maybe a capability isn't the right way to go, I'm not sure. I'll leave
> that to Matthew. Whatever the flag, it should be an immutable state of
> the boot. Though, it probably makes sense as a cap just so that
> non-secure-boot systems can still remove it from containers, etc.

There was interest in ensuring that this wasn't something special-cased
to UEFI Secure Boot, so using a capability seemed like the most
straightforward way - it's fundamentally a restriction on what an
otherwise privileged user is able to do, so it seemed like it fit the
model. But I'm not wed to it in the slightest, and in fact it causes
problems for some userspace (anything that drops all capabilities
suddenly finds itself unable to do something that it expects to be able
to do), so if anyone has any suggestions for a better approach…