linux-kernel - Re: [PATCH RFC] user-namespaced file capabilities

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:	Fri, 20 May 2016 13:28:55 -0500
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Mimi Zohar <zohar@...ux.vnet.ibm.com>
Cc:	"Serge E. Hallyn" <serge@...lyn.com>,
	LKML <linux-kernel@...r.kernel.org>, Jann Horn <jann@...jh.net>,
	Seth Forshee <seth.forshee@...onical.com>,
	LSM <linux-security-module@...r.kernel.org>,
	"Andrew G. Morgan" <morgan@...nel.org>,
	Kees Cook <keescook@...omium.org>,
	Michael Kerrisk-manpages <mtk.manpages@...il.com>,
	"Serge E. Hallyn" <serge.hallyn@...ntu.com>,
	Linux API <linux-api@...r.kernel.org>,
	Andy Lutomirski <luto@...capital.net>,
	Linux Containers <containers@...ts.linux-foundation.org>
Subject: Re: [PATCH RFC] user-namespaced file capabilities - now with more magic

Mimi Zohar <zohar@...ux.vnet.ibm.com> writes:

> On Thu, 2016-05-19 at 22:40 -0500, Serge E. Hallyn wrote:
>> Quoting Mimi Zohar (zohar@...ux.vnet.ibm.com):
>> > On Wed, 2016-05-18 at 16:57 -0500, Serge E. Hallyn wrote:
>
>> > > diff --git a/fs/xattr.c b/fs/xattr.c
>> > > index 4861322..5c0e7ae 100644
>> > > --- a/fs/xattr.c
>> > > +++ b/fs/xattr.c
>> > > @@ -94,11 +94,26 @@ int __vfs_setxattr_noperm(struct dentry *dentry, const char *name,
>> > >  {
>> > >  	struct inode *inode = dentry->d_inode;
>> > >  	int error = -EOPNOTSUPP;
>> > > +	void *wvalue = NULL;
>> > > +	size_t wsize = 0;
>> > >  	int issec = !strncmp(name, XATTR_SECURITY_PREFIX,
>> > >  				   XATTR_SECURITY_PREFIX_LEN);
>> > > 
>> > > -	if (issec)
>> > > +	if (issec) {
>> > >  		inode->i_flags &= ~S_NOSEC;
>> > > +		/* if root in a non-init user_ns tries to set
>> > > +		 * security.capability, write a security.nscapability
>> > > +		 * in its place */
>> > > +		if (!strcmp(name, "security.capability") &&
>> > > +				current_user_ns() != &init_user_ns) {
>> > > +			cap_setxattr_make_nscap(dentry, value, size, &wvalue, &wsize);
>> > > +			if (!wvalue)
>> > > +				return -EPERM;
>> > > +			value = wvalue;
>> > > +			size = wsize;
>> > > +			name = "security.nscapability";
>> > > +		}
>> > 
>> > The call to capable_wrt_inode_uidgid() is hidden behind
>> > cap_setxattr_make_nscap().  Does it make sense to call it here instead,
>> > before the security.capability test?  This would lay the foundation for
>> > doing something similar for IMA.
>> 
>> Might make sense to move that.  Though looking at it with fresh eyes I wonder
>> whether adding less code here at __vfs_setxattr_noperm(), i.e.
>> 
>> 		if (!cap_setxattr_makenscap(dentry, &value, &size, &name))
>> 			return -EPERM;
>> 
>> would be cleaner.
>
> Yes, it would be cleaner,  but I'm suggesting you do all the hard work
> making it generic.  Then the rest of us can follow your lead.  Its more
> likely that you'll get it right.  At a high level, it might look like:
>
>                /* Permit root in a non-init user_ns to modify the security
>                  * namespace xattr equivalents (eg. nscapability, ns_ima, etc). 
>                  */
>                 if ((current_user_ns() != &init_user_ns) &&
>                         capable_wrt_inode_uidgid(inode, CAP_SETFCAP)) {
>
> 			if  security..capability
> 				call capability  /* set nscapability? */
>
> 			else if security.ima 
> 				call ima 	/* set ns_ima? */
> 		}

Hmm.  I am confused about this part of the strategy.

I don't understand the capability vs nscapability distinction.  It seems
to add complexity without benefit.

If I am in a nested user namespace and I try to write a capability on a
file and it has nscapability I can't be allowed to (as a more privileged
user namespace already wrote it).

Not rewriting an existing attribute seems to be the only benefit I can
see to have both a capability and a nscapability attribute vs having
a new version of the capability attribute.

Am I missing something here?

Mimi as for generalizing the code for handling IMA I expect it makes
sense to refactor the code to have shared library functions (or whatever
it takes to generalize the code) when you are ready to implement this
kind of IMA attribute.  That way in the first implementation we can
concentrate on getting the code clean and the sematics correct.

That alone seems to be taking a while.

Eric