From: "Serge E. Hallyn" <serue@us.ibm.com>
To: Casey Schaufler <casey@schaufler-ca.com>
Cc: "Serge E. Hallyn" <serue@us.ibm.com>,
lkml <linux-kernel@vger.kernel.org>,
linux-security-module@vger.kernel.org,
Andrew Morton <akpm@osdl.org>
Subject: Re: [PATCH 0/2] file capabilities: two bugfixes
Date: Fri, 8 Dec 2006 15:16:26 -0600 [thread overview]
Message-ID: <20061208211626.GA30754@sergelap.austin.ibm.com> (raw)
In-Reply-To: <402572.41716.qm@web36607.mail.mud.yahoo.com>
Quoting Casey Schaufler (casey@schaufler-ca.com):
>
> --- "Serge E. Hallyn" <serue@us.ibm.com> wrote:
>
> > ...
> > The other is that root can lose capabilities by
> > executing files with
> > only some capabilities set. The next two patches
> > change these
> > behaviors.
>
> It was the intention of the POSIX group that
> capabilities be independent of uid. I would
> argue that the old bevavior was correct, that
> a program marked to lose a capability ought
> to even if the uid is 0.
Agreed, and if SECURE_NOROOT is set, that is what happens.
But by default SECURE_NOROOT is not set, in which case linux's
implementation of capabilities behaves differently for root.
Without this latest patch, with SECURE_NOROOT not set, what was
actually happening was that the kernel behaved as though
SECURE_NOROOT was not set so long as there was no
security.capability xattr, and always behaved as though
SECURE_NOROOT was set if there was an xattr. That's inconsistent
and confusing behavior.
The worst part is that root can get around running the code
with limited caps by just copying the file and running the
copy. So it adds no security benefit, and adds an
inconsistency/complication which could cause security risks.
-serge
next prev parent reply other threads:[~2006-12-08 21:16 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-12-08 19:36 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 [this message]
2006-12-08 22:08 ` Casey Schaufler
2006-12-09 0:43 ` Seth Arnold
2006-12-11 21:31 ` Crispin Cowan
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=20061208211626.GA30754@sergelap.austin.ibm.com \
--to=serue@us.ibm.com \
--cc=akpm@osdl.org \
--cc=casey@schaufler-ca.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
/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
all inboxes | Powered by JetHome®