linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Kees Cook <keescook@chromium.org>
To: "H. Peter Anvin" <hpa@zytor.com>
Cc: LKML <linux-kernel@vger.kernel.org>,
	Matthew Garrett <matthew.garrett@nebula.com>,
	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, 8 Feb 2013 12:28:00 -0800	[thread overview]
Message-ID: <CAGXu5jLAufTRm=sDST0br_WEkn4o0Hpjv2jDP2Na=cCvuM+MGg@mail.gmail.com> (raw)
In-Reply-To: <dee64752-850c-4d78-b703-f47a985bc13e@email.android.com>

On Fri, Feb 8, 2013 at 12:18 PM, H. Peter Anvin <hpa@zytor.com> wrote:
> Analogy fail.  The /dev/mem lockout applies to system RAM, not MMIO.

Well, that's what I meant by it being "stronger".

> I fear COMPROMISE_KERNEL is becoming the new SYS_ADMIN, which in turn is the new root.  Why?  Because it is inhebtly about a usage model, not about a specific resource.

I can see where you're coming from, but I don't agree. Roughly
speaking, uids should be about organization and filesystem DAC (uid 0
shouldn't be special). SYS_ADMIN is about broad-ranging
configuration/resource access (generally still all in userspace).
There hasn't been a strong distinction between user/kernel space for
uid-0 just because it didn't seem valuable. But now it's clearer, and
COMPROMISE_KERNEL can mark where these lines need to be drawn.

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.

-Kees

> Kees Cook <keescook@chromium.org> wrote:
>
>>On Fri, Feb 8, 2013 at 11:42 AM, H. Peter Anvin <hpa@zytor.com> wrote:
>>> On 02/08/2013 11:18 AM, Kees Cook wrote:
>>>>
>>>> No. CAP_RAWIO is for reading. Writing needs a much stronger check.
>>>
>>> If so, I suspect we need to do this for *all* raw I/O... but I keep
>>> wondering how much more sensitive writing really is than reading.
>>
>>Well, I think there's a reasonable distinction between systems that
>>expect to strictly enforce user-space/kernel-space separation
>>(CAP_COMPROMISE_KERNEL) and things that are fiddling with hardware
>>(CAP_SYS_RAWIO).
>>
>>For example, even things like /dev/mem already have this separation
>>(although it is stronger). You can't open /dev/mem without
>>CAP_SYS_RAWIO, but if you do, you still can't write to RAM in
>>/dev/mem. This might be one of the earliest examples of this
>>distinction, actually.
>>
>>I think it's likely that after a while, we can convert some of these
>>proposed CAP_COMPROMISE_KERNEL checks in always-deny once we figure
>>out how to deal with those areas more safely.
>>
>>-Kees
>>
>>--
>>Kees Cook
>>Chrome OS Security
>
> --
> Sent from my mobile phone. Please excuse brevity and lack of formatting.



--
Kees Cook
Chrome OS Security

  reply	other threads:[~2013-02-08 20:28 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 [this message]
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
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='CAGXu5jLAufTRm=sDST0br_WEkn4o0Hpjv2jDP2Na=cCvuM+MGg@mail.gmail.com' \
    --to=keescook@chromium.org \
    --cc=hpa@zytor.com \
    --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).