All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Serge E. Hallyn" <serue@us.ibm.com>
To: Stephen Smalley <sds@tycho.nsa.gov>
Cc: Igor Zhbanov <izh1979@gmail.com>,
	"J. Bruce Fields" <bfields@fieldses.org>,
	Michael Kerrisk <mtk.manpages@gmail.com>,
	linux-kernel@vger.kernel.org, viro@zeniv.linux.org.uk,
	neilb@suse.de, Trond.Myklebust@netapp.com,
	David Howells <dhowells@redhat.com>,
	Andrew Morgan <morgan@kernel.org>,
	James Morris <jmorris@namei.org>,
	linux-security-module@vger.kernel.org,
	SELinux <selinux@tycho.nsa.gov>
Subject: Re: Ответ: VFS, NFS security bug? Should CAP_MKNOD and CAP_LINUX_IMMUTABLE be added to CAP_FS_MASK?
Date: Wed, 18 Mar 2009 11:47:12 -0500	[thread overview]
Message-ID: <20090318164712.GB27906@us.ibm.com> (raw)
In-Reply-To: <1237393287.12822.50.camel@localhost.localdomain>

Quoting Stephen Smalley (sds@tycho.nsa.gov):
> On Tue, 2009-03-17 at 13:23 -0500, Serge E. Hallyn wrote:
> > But in cap_inode_setxattr, any security.* xattrs are controlled by
> > CAP_SYS_ADMIN.  So do you think that this should be changed to a
> > CAP_XATTR_SECURITY capability which can be added to CAP_FS_MASK?
> 
> I think that would be preferable to CAP_SYS_ADMIN, yes.
> 
> > Or do you think it's ok that fsuid=0 does not allow you to set
> > security.selinux (or security.SMACK64, etc) xattrs when selinux is
> > not compiled in?
> 
> Just to be clear, at present fsuid is irrelevant to setting the
> security.* xattrs since it doesn't affect the CAP_SYS_ADMIN capability
> at all, so it all depends on the initial capability state prior to using
> setfsuid(), typically the full capability set.

Right.

> > (You may have already answered this with your EOPNOTSUPP comment, but
> > I want to make sure I understand right)
> > 
> > > > Does anyone know what the trusted xattrs are used for?
> > > 
> > > Not beyond what attr(5) says about them.
> > 
> > Well, if attr(5) says CAP_SYS_ADMIN being needed is the very
> > thing that defines these xattrs, then changing that seems a
> > bigger deal.  That really does seem akin to changing kernel-user
> > API.
> 
> Perhaps, although it isn't clear that this API is in use by anyone or in
> use in a way that would actually distinguish based on individual
> capability.
> 
> But if you were to add CAP_SYS_ADMIN to CAP_FS_MASK in order to ensure
> that setfsuid() does in fact affect all filesystem accesses, how much
> meaningful difference remains between fsuid==0 and euid==0?  It
> obviously takes you far afield of only affecting filesystem accesses.

Ok, thanks for time.  It's all pretty clear to me now:

CAP_MKNOD and CAP_LINUX_IMMUTABLE need to be added to the CAP_FS_MASK
because, in 2.0 timeframe, fsuid==0 gave you those privileges.

xattrs didn't exist back then, so the setting of security.* and
trusted.* xattrs doesn't need to be enabled by fsuid==0.  So really
CAP_SETFCAP also doesn't need to be added to CAP_FS_MASK either.

I'll send out a patch later today for 2.6, unless Igor wants to
do it (since he's the one who found this originally).

thanks,
-serge

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

WARNING: multiple messages have this Message-ID (diff)
From: "Serge E. Hallyn" <serue@us.ibm.com>
To: Stephen Smalley <sds@tycho.nsa.gov>
Cc: Igor Zhbanov <izh1979@gmail.com>,
	"J. Bruce Fields" <bfields@fieldses.org>,
	Michael Kerrisk <mtk.manpages@gmail.com>,
	linux-kernel@vger.kernel.org, viro@zeniv.linux.org.uk,
	neilb@suse.de, Trond.Myklebust@netapp.com,
	David Howells <dhowells@redhat.com>,
	Andrew Morgan <morgan@kernel.org>,
	James Morris <jmorris@namei.org>,
	linux-security-module@vger.kernel.org,
	SELinux <selinux@tycho.nsa.gov>
Subject: Re: Ответ: VFS, NFS security bug? Should CAP_MKNOD and CAP_LINUX_IMMUTABLE be added to CAP_FS_MASK?
Date: Wed, 18 Mar 2009 11:47:12 -0500	[thread overview]
Message-ID: <20090318164712.GB27906@us.ibm.com> (raw)
In-Reply-To: <1237393287.12822.50.camel@localhost.localdomain>

Quoting Stephen Smalley (sds@tycho.nsa.gov):
> On Tue, 2009-03-17 at 13:23 -0500, Serge E. Hallyn wrote:
> > But in cap_inode_setxattr, any security.* xattrs are controlled by
> > CAP_SYS_ADMIN.  So do you think that this should be changed to a
> > CAP_XATTR_SECURITY capability which can be added to CAP_FS_MASK?
> 
> I think that would be preferable to CAP_SYS_ADMIN, yes.
> 
> > Or do you think it's ok that fsuid=0 does not allow you to set
> > security.selinux (or security.SMACK64, etc) xattrs when selinux is
> > not compiled in?
> 
> Just to be clear, at present fsuid is irrelevant to setting the
> security.* xattrs since it doesn't affect the CAP_SYS_ADMIN capability
> at all, so it all depends on the initial capability state prior to using
> setfsuid(), typically the full capability set.

Right.

> > (You may have already answered this with your EOPNOTSUPP comment, but
> > I want to make sure I understand right)
> > 
> > > > Does anyone know what the trusted xattrs are used for?
> > > 
> > > Not beyond what attr(5) says about them.
> > 
> > Well, if attr(5) says CAP_SYS_ADMIN being needed is the very
> > thing that defines these xattrs, then changing that seems a
> > bigger deal.  That really does seem akin to changing kernel-user
> > API.
> 
> Perhaps, although it isn't clear that this API is in use by anyone or in
> use in a way that would actually distinguish based on individual
> capability.
> 
> But if you were to add CAP_SYS_ADMIN to CAP_FS_MASK in order to ensure
> that setfsuid() does in fact affect all filesystem accesses, how much
> meaningful difference remains between fsuid==0 and euid==0?  It
> obviously takes you far afield of only affecting filesystem accesses.

Ok, thanks for time.  It's all pretty clear to me now:

CAP_MKNOD and CAP_LINUX_IMMUTABLE need to be added to the CAP_FS_MASK
because, in 2.0 timeframe, fsuid==0 gave you those privileges.

xattrs didn't exist back then, so the setting of security.* and
trusted.* xattrs doesn't need to be enabled by fsuid==0.  So really
CAP_SETFCAP also doesn't need to be added to CAP_FS_MASK either.

I'll send out a patch later today for 2.6, unless Igor wants to
do it (since he's the one who found this originally).

thanks,
-serge

  reply	other threads:[~2009-03-18 16:47 UTC|newest]

Thread overview: 58+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-03-11 12:53 VFS, NFS security bug? Should CAP_MKNOD and CAP_LINUX_IMMUTABLE be added to CAP_FS_MASK? Igor Zhbanov
2009-03-11 23:23 ` J. Bruce Fields
2009-03-12 16:03   ` Serge E. Hallyn
2009-03-12 16:31     ` J. Bruce Fields
2009-03-12 16:10   ` Serge E. Hallyn
2009-03-12 19:00     ` J. Bruce Fields
2009-03-12 20:56       ` Igor Zhbanov
2009-03-12 20:21     ` Michael Kerrisk
2009-03-13 17:58       ` J. Bruce Fields
2009-03-13 18:37         ` Ответ: " Igor Zhbanov
2009-03-13 19:00           ` Serge E. Hallyn
2009-03-13 19:00             ` Serge E. Hallyn
2009-03-16 18:21             ` Stephen Smalley
2009-03-16 18:21               ` Stephen Smalley
2009-03-16 18:49               ` Serge E. Hallyn
2009-03-16 18:49                 ` Serge E. Hallyn
2009-03-16 21:00                 ` Stephen Smalley
2009-03-16 21:00                   ` Stephen Smalley
2009-03-16 22:26                   ` Igor Zhbanov
2009-03-16 23:13                   ` Serge E. Hallyn
2009-03-16 23:13                     ` Serge E. Hallyn
2009-03-16 23:17                     ` Igor Zhbanov
2009-03-17 14:20                     ` Stephen Smalley
2009-03-17 14:20                       ` Stephen Smalley
2009-03-17 17:39                       ` Serge E. Hallyn
2009-03-17 17:39                         ` Serge E. Hallyn
2009-03-17 17:52                         ` Stephen Smalley
2009-03-17 17:52                           ` Stephen Smalley
2009-03-17 18:23                           ` Serge E. Hallyn
2009-03-17 18:23                             ` Serge E. Hallyn
2009-03-18 16:17                             ` ?????: " Casey Schaufler
2009-03-18 16:17                               ` Casey Schaufler
2009-03-18 16:38                               ` Serge E. Hallyn
2009-03-18 16:38                                 ` Serge E. Hallyn
2009-03-18 16:21                             ` Ответ: " Stephen Smalley
2009-03-18 16:21                               ` Stephen Smalley
2009-03-18 16:47                               ` Serge E. Hallyn [this message]
2009-03-18 16:47                                 ` Serge E. Hallyn
2009-03-18 16:57                                 ` J. Bruce Fields
2009-03-18 17:24                                   ` Serge E. Hallyn
2009-03-18 17:24                                     ` Serge E. Hallyn
2009-03-16 22:48                 ` J. Bruce Fields
2009-03-16 23:03                   ` Serge E. Hallyn
2009-03-16 23:03                     ` Serge E. Hallyn
2009-03-14 19:20         ` Michael Kerrisk
2009-03-16 14:16           ` Igor Zhbanov
2009-03-16 16:36             ` J. Bruce Fields
2009-03-16 16:46               ` J. Bruce Fields
2009-03-16 17:05                 ` Serge E. Hallyn
2009-03-16 17:04               ` Serge E. Hallyn
2009-03-16 22:54                 ` J. Bruce Fields
2009-03-16 22:59                   ` Serge E. Hallyn
2009-03-23 13:21                 ` unprivileged mounts vs. rmdir (was: VFS, NFS security bug? ...) Miklos Szeredi
2009-03-26 12:43                   ` Pavel Machek
2009-03-26 13:14                     ` Matthew Wilcox
2009-03-27  7:04                     ` Eric W. Biederman
2009-03-12 11:46 ` VFS, NFS security bug? Should CAP_MKNOD and CAP_LINUX_IMMUTABLE be added to CAP_FS_MASK? Igor Zhbanov
     [not found]   ` <f44001920903120446k47590437q95242f7a55c11d57-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2009-03-12 12:25     ` Igor Zhbanov

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=20090318164712.GB27906@us.ibm.com \
    --to=serue@us.ibm.com \
    --cc=Trond.Myklebust@netapp.com \
    --cc=bfields@fieldses.org \
    --cc=dhowells@redhat.com \
    --cc=izh1979@gmail.com \
    --cc=jmorris@namei.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=morgan@kernel.org \
    --cc=mtk.manpages@gmail.com \
    --cc=neilb@suse.de \
    --cc=sds@tycho.nsa.gov \
    --cc=selinux@tycho.nsa.gov \
    --cc=viro@zeniv.linux.org.uk \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.