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 13:23:35 -0500 [thread overview] Message-ID: <20090317182335.GB31633@us.ibm.com> (raw) In-Reply-To: <1237312345.6582.140.camel@localhost.localdomain> Quoting Stephen Smalley (sds@tycho.nsa.gov): > On Tue, 2009-03-17 at 12:39 -0500, Serge E. Hallyn wrote: > > 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? > > Sure - it is only used for filesystem operations. Ok, so then: > > > > 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? > > I'm talking about the dumb NFS server case (non-SELinux NFS server > providing label and data storage to SELinux clients, MAC enforcement > handled client-side). But we aren't there yet, so I don't think we have > to worry about it right now. 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? 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? (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. thanks, -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 13:23:35 -0500 [thread overview] Message-ID: <20090317182335.GB31633@us.ibm.com> (raw) In-Reply-To: <1237312345.6582.140.camel@localhost.localdomain> Quoting Stephen Smalley (sds@tycho.nsa.gov): > On Tue, 2009-03-17 at 12:39 -0500, Serge E. Hallyn wrote: > > 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? > > Sure - it is only used for filesystem operations. Ok, so then: > > > > 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? > > I'm talking about the dumb NFS server case (non-SELinux NFS server > providing label and data storage to SELinux clients, MAC enforcement > handled client-side). But we aren't there yet, so I don't think we have > to worry about it right now. 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? 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? (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. 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.
next prev parent reply other threads:[~2009-03-17 18:23 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 [this message] 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=20090317182335.GB31633@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.