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: <51157C9C.6030501@zytor.com>
Date:	Fri, 08 Feb 2013 14:30:52 -0800
From:	"H. Peter Anvin" <hpa@...or.com>
To:	Kees Cook <keescook@...omium.org>
CC:	Matthew Garrett <matthew.garrett@...ula.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 02/08/2013 01:02 PM, Kees Cook wrote:
> On Fri, Feb 8, 2013 at 12:34 PM, Matthew Garrett
> <matthew.garrett@...ula.com> wrote:
>> 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…
> 
> I don't find it unreasonable to drop all caps and lose access to
> sensitive things. :) That's sort of the point, really. I think a cap
> is the best match. It seems like it should either be a cap or a
> namespace flag, but the latter seems messy.
> 

Caps are fine; the problem is the "putting it all under one cap".  The
semi-problem here is that to preserve backwards compatibility we really
should have a way to have hierarchical caps in Linux (which we currently
don't), but it is not really an issue for this.

Also, keep in mind that there is a very simple way to deny MSR access
completely, which is to not include the driver in your kernel (and not
allow module loading, but if you can load modules you can just load a
module to muck with whatever MSR you want.)

I am still wondering if there are any legitimate uses of CAP_RAWIO &
~CAP_COMPROMISE_KERNEL that can't be used to subvert the latter.  I am
not sure there are.

	-hpa

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