All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Serge E. Hallyn" <serge-A9i7LUbDfNHQT0dZR+AlfA@public.gmane.org>
To: "Eric W. Biederman" <ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
Cc: "Serge E. Hallyn" <serge-A9i7LUbDfNHQT0dZR+AlfA@public.gmane.org>,
	LKML <linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	Jann Horn <jann-XZ1E9jl8jIdeoWH0uzbU5w@public.gmane.org>,
	Seth Forshee
	<seth.forshee-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org>,
	LSM
	<linux-security-module-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	"Andrew G. Morgan"
	<morgan-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
	Kees Cook <keescook-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>,
	Michael Kerrisk-manpages
	<mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
	Linux API <linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	Andy Lutomirski <luto-kltTT9wpgjJwATOyAt5JVQ@public.gmane.org>,
	Linux Containers
	<containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org>,
	Mimi Zohar
	<zohar-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
Subject: Re: [PATCH] user-namespaced file capabilities - now with even more magic
Date: Fri, 27 May 2016 16:27:07 -0500	[thread overview]
Message-ID: <20160527212707.GA13554@mail.hallyn.com> (raw)
In-Reply-To: <87y46vcn3a.fsf-JOvCrm2gF+uungPnsOpG7nhyD016LWXt@public.gmane.org>

Quoting Eric W. Biederman (ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org):
> "Serge E. Hallyn" <serge-A9i7LUbDfNHQT0dZR+AlfA@public.gmane.org> writes:
> 
> > Quoting Eric W. Biederman (ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org):
> >> > @@ -657,8 +898,11 @@ int cap_inode_setxattr(struct dentry *dentry, const char *name,
> >> >  		       const void *value, size_t size, int flags)
> >> >  {
> >> >  	if (!strcmp(name, XATTR_NAME_CAPS)) {
> >> > -		if (!capable(CAP_SETFCAP))
> >> > +		/* Note - we want to use Seth's newer code here instead
> >> > */
> >> ^^^^^^^^^^^^^^^  What are you referring to here?  current_in_userns?
> >
> > Referring specifically to
> >
> > http://kernel.ubuntu.com/git/ubuntu/ubuntu-yakkety.git/commit/security/commoncap.c?id=e1804ed91602bc8ead616c9616de70096b139fa7
> >
> > I just need to think about what precisely we want the rule to be here.
> >
> > It's possible we just drop Seth's patch, as mine already allows writing
> > capabilities (though not v2) when not in init_user_ns, so his patch isn't
> > needed.
> >
> > Seth's patch makes it possible to write v2 capabilitie (which are not
> > namespaced) to a file in non-init user-ns if the userns mounted the fs.
> >
> > Mine does not allow that, ever, but will silently write a v3 capability.
> >
> > Seth's patch never allows writing a file capability unlesss the whole
> > block device was mountd by the caller's user-ns.  Mine allows writing
> > v3 capabilities to such files.
> >
> > So yeah, maybe mine simiply obviates the need for Seths' patch.
> 
> Hmm.
> 
> While there is an obvious conflict the two patches are doing different
> things.
> 
> s_user_ns is the owning user namespace of the filesystem.  And as such
> it is fine to write the old capability in that context.

Ok, right, so I should simply allow that in my patchset.  (Though it still
makes me nervous.)

To make that elegant the flow will need to change a bit, so easiest will
be to indeed wait for the s_user_ns patchset.

> You are making it possible to write the capability in child user
> namespaces, and I presume not allowing stomping a capability set by
> a more privileged user.
> 
> Unless you update your code to decide to write a v2 capability if rootid
> is zero and v3 otherwise the code will still have interesting
> entanglement issues.  Even then the code needs to look at s_user_ns to
> see what rootid should be.
> 
> Earlier today I pushed a for-testing branch to my user-namespace.git
> tree and that has the start of the s_user_ns stuff that I am pretty much
> ready to merge at this point.  I still need to rebase onto 4.7-rc1 and
> retest before I get farther.  But I am serious about getting this stuff
> reviewed and merged into my tree and into Linus' tree next merge window.
> 
> It is way past time.
> 
> Eric

WARNING: multiple messages have this Message-ID (diff)
From: "Serge E. Hallyn" <serge@hallyn.com>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: "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>,
	Linux API <linux-api@vger.kernel.org>,
	Andy Lutomirski <luto@amacapital.net>,
	Linux Containers <containers@lists.linux-foundation.org>,
	Mimi Zohar <zohar@linux.vnet.ibm.com>
Subject: Re: [PATCH] user-namespaced file capabilities - now with even more magic
Date: Fri, 27 May 2016 16:27:07 -0500	[thread overview]
Message-ID: <20160527212707.GA13554@mail.hallyn.com> (raw)
In-Reply-To: <87y46vcn3a.fsf@x220.int.ebiederm.org>

Quoting Eric W. Biederman (ebiederm@xmission.com):
> "Serge E. Hallyn" <serge@hallyn.com> writes:
> 
> > Quoting Eric W. Biederman (ebiederm@xmission.com):
> >> > @@ -657,8 +898,11 @@ int cap_inode_setxattr(struct dentry *dentry, const char *name,
> >> >  		       const void *value, size_t size, int flags)
> >> >  {
> >> >  	if (!strcmp(name, XATTR_NAME_CAPS)) {
> >> > -		if (!capable(CAP_SETFCAP))
> >> > +		/* Note - we want to use Seth's newer code here instead
> >> > */
> >> ^^^^^^^^^^^^^^^  What are you referring to here?  current_in_userns?
> >
> > Referring specifically to
> >
> > http://kernel.ubuntu.com/git/ubuntu/ubuntu-yakkety.git/commit/security/commoncap.c?id=e1804ed91602bc8ead616c9616de70096b139fa7
> >
> > I just need to think about what precisely we want the rule to be here.
> >
> > It's possible we just drop Seth's patch, as mine already allows writing
> > capabilities (though not v2) when not in init_user_ns, so his patch isn't
> > needed.
> >
> > Seth's patch makes it possible to write v2 capabilitie (which are not
> > namespaced) to a file in non-init user-ns if the userns mounted the fs.
> >
> > Mine does not allow that, ever, but will silently write a v3 capability.
> >
> > Seth's patch never allows writing a file capability unlesss the whole
> > block device was mountd by the caller's user-ns.  Mine allows writing
> > v3 capabilities to such files.
> >
> > So yeah, maybe mine simiply obviates the need for Seths' patch.
> 
> Hmm.
> 
> While there is an obvious conflict the two patches are doing different
> things.
> 
> s_user_ns is the owning user namespace of the filesystem.  And as such
> it is fine to write the old capability in that context.

Ok, right, so I should simply allow that in my patchset.  (Though it still
makes me nervous.)

To make that elegant the flow will need to change a bit, so easiest will
be to indeed wait for the s_user_ns patchset.

> You are making it possible to write the capability in child user
> namespaces, and I presume not allowing stomping a capability set by
> a more privileged user.
> 
> Unless you update your code to decide to write a v2 capability if rootid
> is zero and v3 otherwise the code will still have interesting
> entanglement issues.  Even then the code needs to look at s_user_ns to
> see what rootid should be.
> 
> Earlier today I pushed a for-testing branch to my user-namespace.git
> tree and that has the start of the s_user_ns stuff that I am pretty much
> ready to merge at this point.  I still need to rebase onto 4.7-rc1 and
> retest before I get farther.  But I am serious about getting this stuff
> reviewed and merged into my tree and into Linus' tree next merge window.
> 
> It is way past time.
> 
> Eric

  parent reply	other threads:[~2016-05-27 21:27 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-27  7:18 [PATCH] user-namespaced file capabilities - now with even more magic Serge E. Hallyn
2016-05-27  7:18 ` Serge E. Hallyn
     [not found] ` <20160527071807.GA501-7LNsyQBKDXoIagZqoN9o3w@public.gmane.org>
2016-05-27 18:50   ` Eric W. Biederman
2016-05-27 18:50     ` Eric W. Biederman
     [not found]     ` <87y46ve3oe.fsf-JOvCrm2gF+uungPnsOpG7nhyD016LWXt@public.gmane.org>
2016-05-27 19:10       ` Serge E. Hallyn
2016-05-27 19:10       ` Serge E. Hallyn
2016-05-27 19:10         ` Serge E. Hallyn
     [not found]         ` <20160527191034.GA11575-7LNsyQBKDXoIagZqoN9o3w@public.gmane.org>
2016-05-27 19:33           ` Eric W. Biederman
2016-05-27 19:33           ` Eric W. Biederman
2016-05-27 19:33             ` Eric W. Biederman
     [not found]             ` <87y46vcn3a.fsf-JOvCrm2gF+uungPnsOpG7nhyD016LWXt@public.gmane.org>
2016-05-27 21:27               ` Serge E. Hallyn
2016-05-27 21:27               ` Serge E. Hallyn [this message]
2016-05-27 21:27                 ` Serge E. Hallyn
2016-05-27 18:50   ` Eric W. Biederman
  -- strict thread matches above, loose matches on Subject: below --
2016-05-27  7:18 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=20160527212707.GA13554@mail.hallyn.com \
    --to=serge-a9i7lubdfnhqt0dzr+alfa@public.gmane.org \
    --cc=containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \
    --cc=ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org \
    --cc=jann-XZ1E9jl8jIdeoWH0uzbU5w@public.gmane.org \
    --cc=keescook-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org \
    --cc=linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-security-module-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=luto-kltTT9wpgjJwATOyAt5JVQ@public.gmane.org \
    --cc=morgan-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
    --cc=mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
    --cc=seth.forshee-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org \
    --cc=zohar-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org \
    /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 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.