public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Crispin Cowan <crispin@novell.com>
To: "Serge E. Hallyn" <serue@us.ibm.com>,
	lkml <linux-kernel@vger.kernel.org>,
	linux-security-module@vger.kernel.org,
	Andrew Morton <akpm@osdl.org>,
	Stephen Smalley <sds@epoch.ncsc.mil>
Subject: Re: [PATCH 0/2] file capabilities: two bugfixes
Date: Mon, 11 Dec 2006 13:31:08 -0800	[thread overview]
Message-ID: <457DCE1C.7010908@novell.com> (raw)
In-Reply-To: <20061209004346.GG21627@suse.de>

Seth Arnold wrote:
> On Fri, Dec 08, 2006 at 01:36:57PM -0600, Serge E. Hallyn wrote:
>   
>> The other is that root can lose capabilities by executing files with
>> only some capabilities set.  The next two patches change these
>> behaviors.
>>     
> I saw this in my code review and thought that this behaviour was
> intentional. :) It seemed like a good idea to me..
>   
It really depends on which threat you are trying to defend against.

Serge is correct that it does not prevent root from copying the file,
messing with the attributes, and running it anyway. However, I don't see
file capabilities as being intended to try to confine root.

Rather, it seems like it is intended to make it easier to manage what
capabilities should usually be present when the program is run. E.g. the
file has a limited capability set so that root can run it and not have
to think about overtly dropping privs or su'ing to a non-privileged user
to be able to run it safely.

So I'm with Seth; it sounds like a feature, not a bug.

Caveat: I have no clue what the POSIX.1e committee intended. But since
none of the POSIX-alike implementations are compatible with each other
anyway, I don't really care :)

Crispin

-- 
Crispin Cowan, Ph.D.                      http://crispincowan.com/~crispin/
Director of Software Engineering, Novell  http://novell.com
     Hacking is exploiting the gap between "intent" and "implementation"


      reply	other threads:[~2006-12-11 21:32 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-12-08 19:36 [PATCH 0/2] file capabilities: two bugfixes Serge E. Hallyn
2006-12-08 19:38 ` [PATCH 1/2] file capabilities: don't do file caps if MNT_NOSUID Serge E. Hallyn
2006-12-08 19:39 ` [PATCH 2/2] file capabilities: honor !SECURE_NOROOT Serge E. Hallyn
2006-12-08 20:41 ` [PATCH 0/2] file capabilities: two bugfixes Casey Schaufler
2006-12-08 21:16   ` Serge E. Hallyn
2006-12-08 22:08     ` Casey Schaufler
2006-12-09  0:43 ` Seth Arnold
2006-12-11 21:31   ` Crispin Cowan [this message]

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=457DCE1C.7010908@novell.com \
    --to=crispin@novell.com \
    --cc=akpm@osdl.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=sds@epoch.ncsc.mil \
    --cc=serue@us.ibm.com \
    /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