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: Tue, 17 Mar 2009 12:39:03 -0500 [thread overview] Message-ID: <20090317173903.GA31566@us.ibm.com> (raw) In-Reply-To: <1237299633.6582.107.camel@localhost.localdomain> Quoting Stephen Smalley (sds@tycho.nsa.gov): > > So do you think it makes sense to have CAP_MAC_ADMIN and CAP_FOWNER > > in CAP_FS_MASK? In other words are you objecting to CAP_SYS_ADMIN > > because of all of its other implications, or because you disagree > > that labels for security modules should be treated as mere fs data > > here? > > For CAP_FOWNER, yes (and it is already there). CAP_MAC_ADMIN is less Sorry, I meant CAP_SETFCAP. Should it be added? > ideal as it isn't clearly tied to filesystem accesses, and likewise for > CAP_MAC_OVERRIDE (but that one is included in CAP_FS_MASK already). So it is. I didn't realize that. > Ideally the capability space would be partitioned into capabilities that > affect filesystem accesses and the rest so that setfsuid() would yield > the expected behavior of only affecting filesystem access. > CAP_SYS_ADMIN is even less suitable due to its pervasive use outside of > the filesystem. So that's the first concern. > > The second one is that we don't want CAP_SYS_ADMIN (or CAP_MAC_ADMIN) to > be required when setting SELinux labels. Only the SELinux permission > checks should govern setting those labels (aside from the usual DAC > ownership || CAP_FOWNER check). So if a non-selinux kernel is booted, then you think only the usual DAC checks should be required to set selinux labels? Or is this assuming EOPNOTSUPP were returned for setting security.selinux xattrs in such a kernel? > > > uses CAP_SYS_ADMIN to control setting of its own attributes: > > > - SELinux applies a DAC check and its own set of MAC file permission > > > checks, > > > - Smack applies CAP_MAC_ADMIN, > > > - Capabilities applies CAP_SETFCAP. > > > > > > Checking CAP_SYS_ADMIN was really just a fallback to prevent unchecked > > > setting of attributes in the no-LSM case. It might make more sense to > > > return EOPNOTSUPP for any attributes unknown to the enabled security > > > > I suspect that would create a LOT of bug reports. Would requiring > > CAP_MAC_ADMIN seem reasonable? > > It would narrow the scope a bit more, but it still isn't ideal. > > > > module and require you to enable the desired module before setting the > > > attributes these days. > > > http://marc.info/?t=107428809400002&r=1&w=2 > > > > > > I don't think this will make any difference for labeled NFS at present, > > > as the current labeled NFS patches only export the MAC label attribute > > > if the server has the MAC model enabled. So CAP_SYS_ADMIN won't get > > > checked regardless. > > > > > > Trusted namespace is another case where CAP_SYS_ADMIN check is applied > > > on file operations. > > > > Which seems like all the more reason why CAP_SYS_ADMIN would need to > > be added to the CAP_FS_MASK. Or do you mean that check should also be > > changed for something else? (CAP_MAC_ADMIN, or some new CAP_FS_XATTR?) > > I'd favor changing it to a new capability. We have CAP_SETFCAP for > setting file capabilities; why not have CAP_SETTRUSTED for setting > attributes in the trusted namespace? Then adding it to CAP_FS_MASK has > no further side effects beyond controlling filesystem accesses. Does anyone know what the trusted xattrs are used for? -serge
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: Tue, 17 Mar 2009 12:39:03 -0500 [thread overview] Message-ID: <20090317173903.GA31566@us.ibm.com> (raw) In-Reply-To: <1237299633.6582.107.camel@localhost.localdomain> Quoting Stephen Smalley (sds@tycho.nsa.gov): > > So do you think it makes sense to have CAP_MAC_ADMIN and CAP_FOWNER > > in CAP_FS_MASK? In other words are you objecting to CAP_SYS_ADMIN > > because of all of its other implications, or because you disagree > > that labels for security modules should be treated as mere fs data > > here? > > For CAP_FOWNER, yes (and it is already there). CAP_MAC_ADMIN is less Sorry, I meant CAP_SETFCAP. Should it be added? > ideal as it isn't clearly tied to filesystem accesses, and likewise for > CAP_MAC_OVERRIDE (but that one is included in CAP_FS_MASK already). So it is. I didn't realize that. > Ideally the capability space would be partitioned into capabilities that > affect filesystem accesses and the rest so that setfsuid() would yield > the expected behavior of only affecting filesystem access. > CAP_SYS_ADMIN is even less suitable due to its pervasive use outside of > the filesystem. So that's the first concern. > > The second one is that we don't want CAP_SYS_ADMIN (or CAP_MAC_ADMIN) to > be required when setting SELinux labels. Only the SELinux permission > checks should govern setting those labels (aside from the usual DAC > ownership || CAP_FOWNER check). So if a non-selinux kernel is booted, then you think only the usual DAC checks should be required to set selinux labels? Or is this assuming EOPNOTSUPP were returned for setting security.selinux xattrs in such a kernel? > > > uses CAP_SYS_ADMIN to control setting of its own attributes: > > > - SELinux applies a DAC check and its own set of MAC file permission > > > checks, > > > - Smack applies CAP_MAC_ADMIN, > > > - Capabilities applies CAP_SETFCAP. > > > > > > Checking CAP_SYS_ADMIN was really just a fallback to prevent unchecked > > > setting of attributes in the no-LSM case. It might make more sense to > > > return EOPNOTSUPP for any attributes unknown to the enabled security > > > > I suspect that would create a LOT of bug reports. Would requiring > > CAP_MAC_ADMIN seem reasonable? > > It would narrow the scope a bit more, but it still isn't ideal. > > > > module and require you to enable the desired module before setting the > > > attributes these days. > > > http://marc.info/?t=107428809400002&r=1&w=2 > > > > > > I don't think this will make any difference for labeled NFS at present, > > > as the current labeled NFS patches only export the MAC label attribute > > > if the server has the MAC model enabled. So CAP_SYS_ADMIN won't get > > > checked regardless. > > > > > > Trusted namespace is another case where CAP_SYS_ADMIN check is applied > > > on file operations. > > > > Which seems like all the more reason why CAP_SYS_ADMIN would need to > > be added to the CAP_FS_MASK. Or do you mean that check should also be > > changed for something else? (CAP_MAC_ADMIN, or some new CAP_FS_XATTR?) > > I'd favor changing it to a new capability. We have CAP_SETFCAP for > setting file capabilities; why not have CAP_SETTRUSTED for setting > attributes in the trusted namespace? Then adding it to CAP_FS_MASK has > no further side effects beyond controlling filesystem accesses. Does anyone know what the trusted xattrs are used for? -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.
next prev parent reply other threads:[~2009-03-17 17:39 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 [this message] 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=20090317173903.GA31566@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: linkBe 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.