All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stephen Smalley <sds@tycho.nsa.gov>
To: "Serge E. Hallyn" <serue@us.ibm.com>
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: Mon, 16 Mar 2009 14:21:45 -0400	[thread overview]
Message-ID: <1237227705.1035.93.camel@localhost.localdomain> (raw)
In-Reply-To: <20090313190002.GA16025@us.ibm.com>

On Fri, 2009-03-13 at 14:00 -0500, Serge E. Hallyn wrote:
> Quoting Igor Zhbanov (izh1979@gmail.com):
> > But ordinary users can't create devices. It seems to me that in time
> > of implementation of capabilities in kernel 2.4, capabilities related
> > to filesystem was added first. And mark for them contains all above in
> > header file. And when CAP_MKNOD was added later, author just forget to
> > update mask.
> > 
> > If mask was designed to drop all filesystem related capabilities, then
> > it must be expanded, because ordinary users cannot create devices etc.
> 
> I think you thought Bruce was saying we shouldn't change the set of
> capabilities, but he was just asking exactly what changes Michael was
> interested in.
> 
> Igor, thanks for finding this.  I never got your original message.  Do
> you have a patdch to add the two capabilities?  Do you think the
> other two I mentioned (CAP_SYS_ADMIN and CAP_SETFCAP) need to be
> added too?
> 
> I've added Andrew Morgan, LSM and SELinux mailing lists to get another
> opinion about adding those two.  In particular, we'd be adding them
> to the fs_masks becuase CAP_SYS_ADMIN lets you change the selinux
> label, and CAP_SETFCAP lets you change the file capabilities.

I'd be inclined against adding CAP_SYS_ADMIN to the mask; note that it
is only checked for setting SELinux security contexts (or more broadly
any attributes in the security namespace) when SELinux is disabled.  In
the SELinux-enabled case, we are checking SELinux-specific permissions
when setting the SELinux attributes, whether on the client or the
server.

-- 
Stephen Smalley
National Security Agency


WARNING: multiple messages have this Message-ID (diff)
From: Stephen Smalley <sds@tycho.nsa.gov>
To: "Serge E. Hallyn" <serue@us.ibm.com>
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: Mon, 16 Mar 2009 14:21:45 -0400	[thread overview]
Message-ID: <1237227705.1035.93.camel@localhost.localdomain> (raw)
In-Reply-To: <20090313190002.GA16025@us.ibm.com>

On Fri, 2009-03-13 at 14:00 -0500, Serge E. Hallyn wrote:
> Quoting Igor Zhbanov (izh1979@gmail.com):
> > But ordinary users can't create devices. It seems to me that in time
> > of implementation of capabilities in kernel 2.4, capabilities related
> > to filesystem was added first. And mark for them contains all above in
> > header file. And when CAP_MKNOD was added later, author just forget to
> > update mask.
> > 
> > If mask was designed to drop all filesystem related capabilities, then
> > it must be expanded, because ordinary users cannot create devices etc.
> 
> I think you thought Bruce was saying we shouldn't change the set of
> capabilities, but he was just asking exactly what changes Michael was
> interested in.
> 
> Igor, thanks for finding this.  I never got your original message.  Do
> you have a patdch to add the two capabilities?  Do you think the
> other two I mentioned (CAP_SYS_ADMIN and CAP_SETFCAP) need to be
> added too?
> 
> I've added Andrew Morgan, LSM and SELinux mailing lists to get another
> opinion about adding those two.  In particular, we'd be adding them
> to the fs_masks becuase CAP_SYS_ADMIN lets you change the selinux
> label, and CAP_SETFCAP lets you change the file capabilities.

I'd be inclined against adding CAP_SYS_ADMIN to the mask; note that it
is only checked for setting SELinux security contexts (or more broadly
any attributes in the security namespace) when SELinux is disabled.  In
the SELinux-enabled case, we are checking SELinux-specific permissions
when setting the SELinux attributes, whether on the client or the
server.

-- 
Stephen Smalley
National Security Agency


--
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.

  reply	other threads:[~2009-03-16 18:32 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 [this message]
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
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=1237227705.1035.93.camel@localhost.localdomain \
    --to=sds@tycho.nsa.gov \
    --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=selinux@tycho.nsa.gov \
    --cc=serue@us.ibm.com \
    --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.