From: "Serge E. Hallyn" <serue@us.ibm.com> To: "J. Bruce Fields" <bfields@fieldses.org> Cc: Stephen Smalley <sds@tycho.nsa.gov>, Igor Zhbanov <izh1979@gmail.com>, 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 12:24:48 -0500 [thread overview] Message-ID: <20090318172448.GB29523@us.ibm.com> (raw) In-Reply-To: <20090318165730.GA15084@fieldses.org> Quoting J. Bruce Fields (bfields@fieldses.org): > On Wed, Mar 18, 2009 at 11:47:12AM -0500, Serge E. Hallyn wrote: > > 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. > > Are we left with any simple one-sentence description of what CAP_FS_MASK > means? (Other than just a particular list of bits?) I'm just wondering > how additional bits will get decided in the future. It means all the privileges that fsuid==0 historically meant. At one time in the past, that meant CAP_MKNOD and CAP_LINUX_IMMUTABLE. It has never meant setting security.* and trusted.* xattrs. We could also define it as follows: CAP_FS_MASK is the privilege to bypass all fs-related DAC permissions security.* and trusted.* xattrs are MAC fs permissions or something like that. I guess one or both of those should go as a comment into capability.h > > 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). > > OK, apologies if I jumped the gun on the nfsd-specific patch--I lost Nonsense, I appreciate it... And there's certainly still a chance that there will be objections to my interpretation, whereas the NFSD bit seems straightened out. > track of this discussion, thought it might take longer, and wanted to > get the one patch into 2.6.30. Feel free to revert that, or ignore it > and leave it to me to revert it afterwards, as convenient.... I'm not sure what the best path forward is, so I'll go ahead and incorporate your patch into mine for now. thanks, -serge
WARNING: multiple messages have this Message-ID (diff)
From: "Serge E. Hallyn" <serue@us.ibm.com> To: "J. Bruce Fields" <bfields@fieldses.org> Cc: Stephen Smalley <sds@tycho.nsa.gov>, Igor Zhbanov <izh1979@gmail.com>, 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 12:24:48 -0500 [thread overview] Message-ID: <20090318172448.GB29523@us.ibm.com> (raw) In-Reply-To: <20090318165730.GA15084@fieldses.org> Quoting J. Bruce Fields (bfields@fieldses.org): > On Wed, Mar 18, 2009 at 11:47:12AM -0500, Serge E. Hallyn wrote: > > 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. > > Are we left with any simple one-sentence description of what CAP_FS_MASK > means? (Other than just a particular list of bits?) I'm just wondering > how additional bits will get decided in the future. It means all the privileges that fsuid==0 historically meant. At one time in the past, that meant CAP_MKNOD and CAP_LINUX_IMMUTABLE. It has never meant setting security.* and trusted.* xattrs. We could also define it as follows: CAP_FS_MASK is the privilege to bypass all fs-related DAC permissions security.* and trusted.* xattrs are MAC fs permissions or something like that. I guess one or both of those should go as a comment into capability.h > > 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). > > OK, apologies if I jumped the gun on the nfsd-specific patch--I lost Nonsense, I appreciate it... And there's certainly still a chance that there will be objections to my interpretation, whereas the NFSD bit seems straightened out. > track of this discussion, thought it might take longer, and wanted to > get the one patch into 2.6.30. Feel free to revert that, or ignore it > and leave it to me to revert it afterwards, as convenient.... I'm not sure what the best path forward is, so I'll go ahead and incorporate your patch into mine for now. 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-18 17:25 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 2009-03-18 16:47 ` Serge E. Hallyn 2009-03-18 16:57 ` J. Bruce Fields 2009-03-18 17:24 ` Serge E. Hallyn [this message] 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=20090318172448.GB29523@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.