public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andy Lutomirski <luto@stanford.edu>
To: Chris Wright <chrisw@osdl.org>
Cc: Stephen Smalley <sds@epoch.ncsc.mil>,
	Andrew Morton <akpm@osdl.org>,
	luto@myrealbox.com, linux-kernel@vger.kernel.org
Subject: Re: capabilitiescompute_cred
Date: Fri, 02 Apr 2004 22:21:06 +0200	[thread overview]
Message-ID: <406DCB32.8070403@stanford.edu> (raw)
In-Reply-To: <20040402111554.E21045@build.pdx.osdl.net>

Chris Wright wrote:
>>IMHO, capabilities are a broken idea anyway, and should ultimately be
>>replaced entirely using Type Enforcement (which SELinux includes).  A
>>comparison of the two approaches is in
>>http://www.securecomputing.com/pdf/secureos.pdf.  Today we still stack
>>SELinux with the capabilities module, but long term, I'd like to see us
>>just drop capabilities and use TE by itself to manage privileges.
> 
> 
> I have the same dislike for capabilities.  It's more like a wart than
> a feature.  I get requests to have RBAC be the core priv system rather
> than capabilities.

I agree in principle, but it would still be nice to have a simple way to 
have useful capabilities without setting up a MAC system.  I don't see a 
capabilities fix adding any significant amount of code; it just takes 
some effort to get it right.

> 
> In the meantime, I've often idly wondered why we don't simply inherit as
> advertised.  The patch below does this, but I haven't even started
> looking for security sensitive failure modes.

I'm not sure that introduces security problems, but I'm also not sure it 
fixes much.  You can find my attempts to get it right in the 
linux-kernel archives, and I'll probably try to get something into 2.7 
when it forks.  With or without MAC, having a functioning capability 
system wouldn't hurt security.

> 
> thanks,
> -chris

       reply	other threads:[~2004-04-02 20:21 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20040402033231.05c0c337.akpm@osdl.org>
     [not found] ` <1080912069.27706.42.camel@moss-spartans.epoch.ncsc.mil>
     [not found]   ` <20040402111554.E21045@build.pdx.osdl.net>
2004-04-02 20:21     ` Andy Lutomirski [this message]
2004-04-02 21:03       ` capabilitiescompute_cred Chris Wright
2004-04-02 21:47       ` capabilitiescompute_cred Stephen Smalley
2004-04-03 15:41         ` capabilitiescompute_cred Andy Lutomirski

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=406DCB32.8070403@stanford.edu \
    --to=luto@stanford.edu \
    --cc=akpm@osdl.org \
    --cc=chrisw@osdl.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@myrealbox.com \
    --cc=sds@epoch.ncsc.mil \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox