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 14:58:28 -0800	[thread overview]
Message-ID: <511C1A94.8020804@schaufler-ca.com> (raw)
In-Reply-To: <511C1325.5060601@zytor.com>

On 2/13/2013 2:26 PM, H. Peter Anvin wrote:
> On 02/13/2013 09:51 AM, Casey Schaufler wrote:
>>
>> You can't add a new capability where there is an existing capability
>> that can be remotely argued to be appropriate.
>>
>> If you tried to "fix" CAP_SYS_RAWIO and/or CAP_SYS_ADMIN you'd end
>> up with hundreds of capabilities.
>>
>> Your particular problem is *not* so important that you get a
>> capability all to yourself.
>>
>
> {facepalm}
>
> 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.

>
> Capabilities need to be associated with resources, not use cases.

There is no such thing as a "resource" in the Linux security
policy model. The Linux security policy model is based on
subjects (tasks) accessing objects (e.g. files). Capabilities
provide a granular mechanism for granting privilege to
violate the Linux security policy.

Because in the Bad Old days of Unix "superuser privilege"
also granted rights to preform configuration activities it
was not possible to eliminate the superuser without extending
the capability mechanism to include these. Thus, there are two
sorts of capabilities, those controlling privileged access and
those controlling restricted activities.

In both cases what you are controlling is an activity. Sorry,
but that is the way it is defined.

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.

>
>     -hpa
>
>


  reply	other threads:[~2013-02-13 22:58 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 [this message]
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=511C1A94.8020804@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).