lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Wed, 18 Mar 2009 12:24:48 -0500
From:	"Serge E. Hallyn" <serue@...ibm.com>
To:	"J. Bruce Fields" <bfields@...ldses.org>
Cc:	Stephen Smalley <sds@...ho.nsa.gov>,
	Igor Zhbanov <izh1979@...il.com>,
	Michael Kerrisk <mtk.manpages@...il.com>,
	linux-kernel@...r.kernel.org, viro@...iv.linux.org.uk,
	neilb@...e.de, Trond.Myklebust@...app.com,
	David Howells <dhowells@...hat.com>,
	Andrew Morgan <morgan@...nel.org>,
	James Morris <jmorris@...ei.org>,
	linux-security-module@...r.kernel.org,
	SELinux <selinux@...ho.nsa.gov>
Subject: Re: Ответ: VFS, NFS security bug? Should CAP_MKNOD and CAP_LINUX_IMMUTABLE be added to
	CAP_FS_MASK?

Quoting J. Bruce Fields (bfields@...ldses.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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ