linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "H. Peter Anvin" <hpa@zytor.com>
To: Kees Cook <keescook@chromium.org>
Cc: Matthew Garrett <matthew.garrett@nebula.com>,
	LKML <linux-kernel@vger.kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, "x86@kernel.org" <x86@kernel.org>,
	"linux-efi@vger.kernel.org" <linux-efi@vger.kernel.org>,
	linux-security-module <linux-security-module@vger.kernel.org>
Subject: Re: [PATCH] x86: Lock down MSR writing in secure boot
Date: Fri, 08 Feb 2013 14:30:52 -0800	[thread overview]
Message-ID: <51157C9C.6030501@zytor.com> (raw)
In-Reply-To: <CAGXu5jKo2PfMBO4A0ZgQcrPuj8OHNaff+CjAesOAWkZc0vB9+Q@mail.gmail.com>

On 02/08/2013 01:02 PM, Kees Cook wrote:
> On Fri, Feb 8, 2013 at 12:34 PM, Matthew Garrett
> <matthew.garrett@nebula.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


  parent reply	other threads:[~2013-02-08 22:31 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-02-08 19:12 Kees Cook
2013-02-08 19:17 ` H. Peter Anvin
2013-02-08 19:18   ` Kees Cook
2013-02-08 19:42     ` H. Peter Anvin
2013-02-08 20:14       ` Kees Cook
2013-02-08 20:18         ` H. Peter Anvin
2013-02-08 20:28           ` Kees Cook
2013-02-08 20:34             ` Matthew Garrett
2013-02-08 21:02               ` Kees Cook
2013-02-08 21:07                 ` Matthew Garrett
2013-02-08 21:14                   ` Josh Boyer
2013-02-08 23:09                     ` Andy Lutomirski
2013-02-08 22:30                 ` H. Peter Anvin [this message]
2013-02-08 23:06                   ` Borislav Petkov
2013-02-08 23:26                     ` Matthew Garrett
2013-02-09  1:22                       ` H. Peter Anvin
2013-02-09  1:29                         ` Matthew Garrett
2013-02-09  6:45                           ` Kees Cook
2013-02-09  9:29                             ` Borislav Petkov
2013-02-09 15:10                               ` Kees Cook
2013-02-09 15:11                               ` Matthew Garrett
2013-02-13  0:48                                 ` H. Peter Anvin
2013-02-13  5:39                                   ` Matthew Garrett
2013-02-13  6:12                                     ` H. Peter Anvin
2013-02-13  6:27                                       ` Matthew Garrett
2013-02-13  6:33                                         ` H. Peter Anvin
2013-02-13  6:41                                           ` Matthew Garrett
2013-02-13 17:20                                             ` H. Peter Anvin
2013-02-13 17:26                                               ` Matthew Garrett
2013-02-13 17:51                                                 ` Casey Schaufler
2013-02-13 17:56                                                   ` Matthew Garrett
2013-02-13 18:44                                                     ` H. Peter Anvin
2013-02-13 18:51                                                       ` Matthew Garrett
2013-02-13 22:26                                                   ` H. Peter Anvin
2013-02-13 22:58                                                     ` Casey Schaufler
2013-02-14  0:25                                                       ` H. Peter Anvin
2013-02-14  0:44                                                         ` Casey Schaufler
2013-02-14  1:04                                                           ` Matthew Garrett
2013-02-14  1:08                                                             ` H. Peter Anvin
2013-02-14  2:46                                                               ` Matthew Garrett
2013-02-14  1:34                                                             ` Casey Schaufler
2013-02-13  8:27                                           ` Paolo Bonzini
2013-02-13 17:21                                             ` H. Peter Anvin
2013-02-13 17:22                                             ` H. Peter Anvin
2013-02-13 19:55                                               ` Paolo Bonzini
2013-02-13 22:24                                                 ` H. Peter Anvin
2013-02-08 19:17 ` Matthew Garrett
2013-02-08 19:21   ` Kees Cook
2013-02-08 19:27     ` Matthew Garrett

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=51157C9C.6030501@zytor.com \
    --to=hpa@zytor.com \
    --cc=keescook@chromium.org \
    --cc=linux-efi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=matthew.garrett@nebula.com \
    --cc=mingo@redhat.com \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.org \
    --subject='Re: [PATCH] x86: Lock down MSR writing in secure boot' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).