linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Casey Schaufler <casey@schaufler-ca.com>
To: "H. Peter Anvin" <hpa@zytor.com>
Cc: Matthew Garrett <matthew.garrett@nebula.com>,
	Borislav Petkov <bp@alien8.de>, Kees Cook <keescook@chromium.org>,
	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>,
	Casey Schaufler <casey@schaufler-ca.com>
Subject: Re: [PATCH] x86: Lock down MSR writing in secure boot
Date: Wed, 13 Feb 2013 16:44:57 -0800	[thread overview]
Message-ID: <511C3389.5090604@schaufler-ca.com> (raw)
In-Reply-To: <511C2F0C.3060803@zytor.com>

On 2/13/2013 4:25 PM, H. Peter Anvin wrote:
> On 02/13/2013 02:58 PM, Casey Schaufler wrote:
>>> This is exactly the kind of thinking which has led to the capability
>>> system being so bloody useless.
>> The reason the capability system is "bloody useless" is
>> that no one wants to update the core system applications to
>> use it in favor of good old fashioned worked for dad and
>> works for me too superuser.
>>
> Because, in large part because a bunch of the capabilities are so close
> to equivalent to "superuser" that the distinction is meaningless... so
> why go through the hassle?  (This is especially so since it was a *long*
> time before the filesystem had any notion of capabilities, and so you
> had to make your app run as root anyway before you could drop the
> capabilities... and some of the people who tried failed spectacularly
> and opened up new security holes.)

Yes. I know. I was one of the people who wrote the P1003.1e/2c spec.
I implemented a rootless Unix system. The infamous sendmail capability
blowup was not my code, but it was my fault. In the Linux world we have
had a terrible problem with no one implementing the next step because
no one is eager to have the next bit because you can't do everything
without that next step.

>> I understand that you want capabilities to be associated with
>> resources. That is *not* what we have, and arguing that its
>> what we should have is pointless because Linux does not even
>> have a concept of resources.
>>
> OK, fine, call it "activities".  This is still distinct from "usage
> models", and that's where we're just broken.
>
> I may look into seeing if there is any sane way we can use the existing
> API to define hierarchical capabilities, which at least should let us
> split existing capabilities just like we used capabilities to split root.

If you want that sort of granularity throw yourself on the SELinux
bandwagon. Fine grained capabilities are insane and unmanageable
and will only lead to tears. Security is despised because of the
notion that making systems impossible to use is a good thing.

>
> 	-hpa
>
>


  reply	other threads:[~2013-02-14  0:44 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
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 [this message]
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=511C3389.5090604@schaufler-ca.com \
    --to=casey@schaufler-ca.com \
    --cc=bp@alien8.de \
    --cc=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).