public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Serge E. Hallyn" <serge@hallyn.com>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Mimi Zohar <zohar@linux.vnet.ibm.com>,
	"Serge E. Hallyn" <serge@hallyn.com>,
	LKML <linux-kernel@vger.kernel.org>, Jann Horn <jann@thejh.net>,
	Seth Forshee <seth.forshee@canonical.com>,
	LSM <linux-security-module@vger.kernel.org>,
	"Andrew G. Morgan" <morgan@kernel.org>,
	Kees Cook <keescook@chromium.org>,
	Michael Kerrisk-manpages <mtk.manpages@gmail.com>,
	"Serge E. Hallyn" <serge.hallyn@ubuntu.com>,
	Linux API <linux-api@vger.kernel.org>,
	Andy Lutomirski <luto@amacapital.net>,
	Linux Containers <containers@lists.linux-foundation.org>
Subject: Re: [PATCH RFC] user-namespaced file capabilities - now with more magic
Date: Fri, 20 May 2016 14:26:07 -0500	[thread overview]
Message-ID: <20160520192607.GA11601@mail.hallyn.com> (raw)
In-Reply-To: <87mvnklh20.fsf@x220.int.ebiederm.org>

Quoting Eric W. Biederman (ebiederm@xmission.com):
> Mimi Zohar <zohar@linux.vnet.ibm.com> writes:
> 
> > On Thu, 2016-05-19 at 22:40 -0500, Serge E. Hallyn wrote:
> >> Quoting Mimi Zohar (zohar@linux.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.

...  Well, yes, we could simply make a new version of security.capability
xattr, and make rootid == 0 mean it was written by the init_user_ns.  Is
that what you mean?

-serge

  parent reply	other threads:[~2016-05-20 19:26 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-22 17:26 namespaced file capabilities serge.hallyn
2016-04-22 17:26 ` [PATCH 1/1] simplified security.nscapability xattr serge.hallyn
2016-04-26 19:46   ` Seth Forshee
2016-04-26 21:59   ` Kees Cook
2016-04-26 22:26     ` Serge E. Hallyn
2016-04-26 22:39       ` Kees Cook
2016-04-27  4:39         ` Serge E. Hallyn
2016-04-27  8:09         ` Jann Horn
2016-05-02  3:54         ` Serge E. Hallyn
2016-05-02 18:31           ` Michael Kerrisk (man-pages)
2016-05-02 21:31           ` Eric W. Biederman
     [not found]             ` <CALQRfL7mfpyudWs4Z8W5Zi8CTG-9O0OvrCnRU7pk0MXtsLBd0A@mail.gmail.com>
2016-05-03  4:50               ` Eric W. Biederman
2016-05-10 19:00                 ` Serge E. Hallyn
2016-05-03  5:19               ` Serge E. Hallyn
2016-05-03  5:54                 ` Eric W. Biederman
2016-05-03 14:25                   ` Serge E. Hallyn
2016-05-10 19:03                     ` Serge E. Hallyn
2016-05-07 23:10                   ` Jann Horn
2016-05-11 21:02                     ` Serge E. Hallyn
2016-05-16 21:15                       ` Serge E. Hallyn
2016-05-16 21:48                         ` Serge E. Hallyn
2016-05-18 21:57                           ` [PATCH RFC] user-namespaced file capabilities - now with more magic Serge E. Hallyn
2016-05-19 20:53                             ` Mimi Zohar
2016-05-20  3:40                               ` Serge E. Hallyn
2016-05-20 11:19                                 ` Mimi Zohar
2016-05-20 18:28                                   ` Eric W. Biederman
2016-05-20 19:09                                     ` Mimi Zohar
2016-05-20 19:11                                       ` Eric W. Biederman
2016-05-20 19:26                                     ` Serge E. Hallyn [this message]
2016-05-20 19:42                                       ` Eric W. Biederman
2016-05-20 19:59                                         ` Serge E. Hallyn
2016-05-20 23:23                                           ` Mimi Zohar
2016-05-20 23:32                                             ` Serge E. Hallyn

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=20160520192607.GA11601@mail.hallyn.com \
    --to=serge@hallyn.com \
    --cc=containers@lists.linux-foundation.org \
    --cc=ebiederm@xmission.com \
    --cc=jann@thejh.net \
    --cc=keescook@chromium.org \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=luto@amacapital.net \
    --cc=morgan@kernel.org \
    --cc=mtk.manpages@gmail.com \
    --cc=serge.hallyn@ubuntu.com \
    --cc=seth.forshee@canonical.com \
    --cc=zohar@linux.vnet.ibm.com \
    /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: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox