All of lore.kernel.org
 help / color / mirror / Atom feed
From: ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org (Eric W. Biederman)
To: "Serge E. Hallyn" <serge-A9i7LUbDfNHQT0dZR+AlfA@public.gmane.org>
Cc: Seth Forshee
	<seth.forshee-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org>,
	lkml <linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-security-module-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	Kees Cook <keescook-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>,
	Andreas Gruenbacher
	<agruenba-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
	Andy Lutomirski <luto-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
	"Andrew G. Morgan"
	<morgan-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Subject: Re: [PATCH] Introduce v3 namespaced file capabilities
Date: Thu, 27 Apr 2017 12:00:25 -0500	[thread overview]
Message-ID: <874lx9zsye.fsf@xmission.com> (raw)
In-Reply-To: <20170427165245.GA794-7LNsyQBKDXoIagZqoN9o3w@public.gmane.org> (Serge E. Hallyn's message of "Thu, 27 Apr 2017 11:52:45 -0500")

"Serge E. Hallyn" <serge-A9i7LUbDfNHQT0dZR+AlfA@public.gmane.org> writes:

> Quoting Eric W. Biederman (ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org):
>> ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org (Eric W. Biederman) writes:
>> 
>> > "Serge E. Hallyn" <serge-A9i7LUbDfNHQT0dZR+AlfA@public.gmane.org> writes:
>> >
>> >> Quoting Eric W. Biederman (ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org):
>> >>> 
>> >>> "Serge E. Hallyn" <serge-A9i7LUbDfNHQT0dZR+AlfA@public.gmane.org> writes:
>> >>> 
>> >>> > diff --git a/fs/xattr.c b/fs/xattr.c
>> >>> > index 7e3317c..75cc65a 100644
>> >>> > --- a/fs/xattr.c
>> >>> > +++ b/fs/xattr.c
>> >>> > @@ -170,12 +170,29 @@ int __vfs_setxattr_noperm(struct dentry *dentry, const char *name,
>> >>> >  		const void *value, size_t size, int flags)
>> >>> >  {
>> >>> >  	struct inode *inode = dentry->d_inode;
>> >>> > -	int error = -EAGAIN;
>> >>> > +	int error;
>> >>> > +	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 (!strcmp(name, "security.capability")) {
>> >>> > +			error = cap_setxattr_convert_nscap(dentry, value, size,
>> >>> > +					&wvalue, &wsize);
>> >>> > +			if (error < 0)
>> >>> > +				return error;
>> >>> > +			if (wvalue) {
>> >>> > +				value = wvalue;
>> >>> > +				size = wsize;
>> >>> > +			}
>> >>> > +		}
>> >>> > +	}
>> >>> > +
>> >>> > +	error = -EAGAIN;
>> >>> > +
>> >>> 
>> >>> Why is the conversion in __vfs_setxattr_noperm and not in setattr as
>> >>> was done for posix_acl_fix_xattr_from_user?
>> >>
>> >> I think I was thinking I wanted to catch all the vfs_setxattr operations,
>> >> but I don't think that's right.  Moving to setxattr seems right.  I'll
>> >> look around a bit more.
>> >
>> > Thanks.  This is one of these little details that we want a good answer
>> > to why there.  If you can document that in your patch description when
>> > you resend I would appreciate it.
>> 
>> Ok. Grrr.
>> 
>> Looking at this a little more getting it correct where we call the
>> conversion operation is critical. 
>> 
>> I believe the current placement of cap_setxattr_convert_nscap is
>> actively wrong.  In particular unless I am misleading something this
>> will trigger multiple conversions when setting one of these attributes
>> on overlayfs.
>> 
>> The stragey I adopted for for posix acls is:
>> 
>>    On a write from userspace convert from current_user_ns() to &init_user_ns.
>>    On a write to the filesystem convert from &init_user_ns to fs_user_ns.
>>    
>>    On a read from the filesystem convert from fs_user_ns to &init_user_ns
>>    On a read from the kernel to userspace convert from &init_user_ns
>>       to current_user_ns().
>> 
>> Overall a good strategy but no one we can trivially adopt for the
>> capability xattr as the second write to filesystem method does not
>> appear to actually exist for anything except for posix acls.
>> 
>> I need to think a little more about how we want to accomplish this for
>> the capability xattr.  My apoligies for leading you down a path that has
>> all of these bumps and then being sufficiently distracted not to help
>> you through this maze.
>> 
>> The only easy solution I can see is to just always keep things in
>> &init_user_ns inside the kernel.   That works until we bring fuse or
>> other unprivileged mounts onboard that have storage outside of the
>> kernel.
>> 
>> Seth and I will have to rework that for fuse support but that sounds
>> better than not letting such an issue prevent us from merging the code.
>
> Ok, in the meantime I've made a few updates in my tree which I think
> make the code a lot nicer (and do move the conversion to setxattr()),
> but there's a bug in that which I'm still trying to nail down.  I'll
> send a new version when I get that figured, and we can see how close
> to ok that is.
>
> Note that upstream cap_inode_removexattr and cap_inode_setxattr()
> upstream still don't respect the fs_user_ns properly either (the
> proper code is in the Ubuntu kernel, maybe it's in your -next
> tree, I don't know how you and Seth are coordinating that)

Oh yes.  The relaxation of permissions.  I remember holding off
on that until we knew the core vfs work was done.  At this point I don't
think it is necessary to keep holding off.  It seemed prudent before we
got all of the s_user_ns bits used in all of the proper places.

At this point I think it was just worry about the last little vfs bits
has been challenging enough that we just haven't gotten too it.

Eric

WARNING: multiple messages have this Message-ID (diff)
From: ebiederm@xmission.com (Eric W. Biederman)
To: linux-security-module@vger.kernel.org
Subject: [PATCH] Introduce v3 namespaced file capabilities
Date: Thu, 27 Apr 2017 12:00:25 -0500	[thread overview]
Message-ID: <874lx9zsye.fsf@xmission.com> (raw)
In-Reply-To: <20170427165245.GA794@mail.hallyn.com> (Serge E. Hallyn's message of "Thu, 27 Apr 2017 11:52:45 -0500")

"Serge E. Hallyn" <serge@hallyn.com> writes:

> Quoting Eric W. Biederman (ebiederm at xmission.com):
>> ebiederm at xmission.com (Eric W. Biederman) writes:
>> 
>> > "Serge E. Hallyn" <serge@hallyn.com> writes:
>> >
>> >> Quoting Eric W. Biederman (ebiederm at xmission.com):
>> >>> 
>> >>> "Serge E. Hallyn" <serge@hallyn.com> writes:
>> >>> 
>> >>> > diff --git a/fs/xattr.c b/fs/xattr.c
>> >>> > index 7e3317c..75cc65a 100644
>> >>> > --- a/fs/xattr.c
>> >>> > +++ b/fs/xattr.c
>> >>> > @@ -170,12 +170,29 @@ int __vfs_setxattr_noperm(struct dentry *dentry, const char *name,
>> >>> >  		const void *value, size_t size, int flags)
>> >>> >  {
>> >>> >  	struct inode *inode = dentry->d_inode;
>> >>> > -	int error = -EAGAIN;
>> >>> > +	int error;
>> >>> > +	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 (!strcmp(name, "security.capability")) {
>> >>> > +			error = cap_setxattr_convert_nscap(dentry, value, size,
>> >>> > +					&wvalue, &wsize);
>> >>> > +			if (error < 0)
>> >>> > +				return error;
>> >>> > +			if (wvalue) {
>> >>> > +				value = wvalue;
>> >>> > +				size = wsize;
>> >>> > +			}
>> >>> > +		}
>> >>> > +	}
>> >>> > +
>> >>> > +	error = -EAGAIN;
>> >>> > +
>> >>> 
>> >>> Why is the conversion in __vfs_setxattr_noperm and not in setattr as
>> >>> was done for posix_acl_fix_xattr_from_user?
>> >>
>> >> I think I was thinking I wanted to catch all the vfs_setxattr operations,
>> >> but I don't think that's right.  Moving to setxattr seems right.  I'll
>> >> look around a bit more.
>> >
>> > Thanks.  This is one of these little details that we want a good answer
>> > to why there.  If you can document that in your patch description when
>> > you resend I would appreciate it.
>> 
>> Ok. Grrr.
>> 
>> Looking at this a little more getting it correct where we call the
>> conversion operation is critical. 
>> 
>> I believe the current placement of cap_setxattr_convert_nscap is
>> actively wrong.  In particular unless I am misleading something this
>> will trigger multiple conversions when setting one of these attributes
>> on overlayfs.
>> 
>> The stragey I adopted for for posix acls is:
>> 
>>    On a write from userspace convert from current_user_ns() to &init_user_ns.
>>    On a write to the filesystem convert from &init_user_ns to fs_user_ns.
>>    
>>    On a read from the filesystem convert from fs_user_ns to &init_user_ns
>>    On a read from the kernel to userspace convert from &init_user_ns
>>       to current_user_ns().
>> 
>> Overall a good strategy but no one we can trivially adopt for the
>> capability xattr as the second write to filesystem method does not
>> appear to actually exist for anything except for posix acls.
>> 
>> I need to think a little more about how we want to accomplish this for
>> the capability xattr.  My apoligies for leading you down a path that has
>> all of these bumps and then being sufficiently distracted not to help
>> you through this maze.
>> 
>> The only easy solution I can see is to just always keep things in
>> &init_user_ns inside the kernel.   That works until we bring fuse or
>> other unprivileged mounts onboard that have storage outside of the
>> kernel.
>> 
>> Seth and I will have to rework that for fuse support but that sounds
>> better than not letting such an issue prevent us from merging the code.
>
> Ok, in the meantime I've made a few updates in my tree which I think
> make the code a lot nicer (and do move the conversion to setxattr()),
> but there's a bug in that which I'm still trying to nail down.  I'll
> send a new version when I get that figured, and we can see how close
> to ok that is.
>
> Note that upstream cap_inode_removexattr and cap_inode_setxattr()
> upstream still don't respect the fs_user_ns properly either (the
> proper code is in the Ubuntu kernel, maybe it's in your -next
> tree, I don't know how you and Seth are coordinating that)

Oh yes.  The relaxation of permissions.  I remember holding off
on that until we knew the core vfs work was done.  At this point I don't
think it is necessary to keep holding off.  It seemed prudent before we
got all of the s_user_ns bits used in all of the proper places.

At this point I think it was just worry about the last little vfs bits
has been challenging enough that we just haven't gotten too it.

Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

WARNING: multiple messages have this Message-ID (diff)
From: ebiederm@xmission.com (Eric W. Biederman)
To: "Serge E. Hallyn" <serge@hallyn.com>
Cc: Seth Forshee <seth.forshee@canonical.com>,
	lkml <linux-kernel@vger.kernel.org>,
	linux-api@vger.kernel.org, linux-security-module@vger.kernel.org,
	Kees Cook <keescook@chromium.org>,
	Andreas Gruenbacher <agruenba@redhat.com>,
	Andy Lutomirski <luto@kernel.org>,
	"Andrew G. Morgan" <morgan@kernel.org>
Subject: Re: [PATCH] Introduce v3 namespaced file capabilities
Date: Thu, 27 Apr 2017 12:00:25 -0500	[thread overview]
Message-ID: <874lx9zsye.fsf@xmission.com> (raw)
In-Reply-To: <20170427165245.GA794@mail.hallyn.com> (Serge E. Hallyn's message of "Thu, 27 Apr 2017 11:52:45 -0500")

"Serge E. Hallyn" <serge@hallyn.com> writes:

> Quoting Eric W. Biederman (ebiederm@xmission.com):
>> ebiederm@xmission.com (Eric W. Biederman) writes:
>> 
>> > "Serge E. Hallyn" <serge@hallyn.com> writes:
>> >
>> >> Quoting Eric W. Biederman (ebiederm@xmission.com):
>> >>> 
>> >>> "Serge E. Hallyn" <serge@hallyn.com> writes:
>> >>> 
>> >>> > diff --git a/fs/xattr.c b/fs/xattr.c
>> >>> > index 7e3317c..75cc65a 100644
>> >>> > --- a/fs/xattr.c
>> >>> > +++ b/fs/xattr.c
>> >>> > @@ -170,12 +170,29 @@ int __vfs_setxattr_noperm(struct dentry *dentry, const char *name,
>> >>> >  		const void *value, size_t size, int flags)
>> >>> >  {
>> >>> >  	struct inode *inode = dentry->d_inode;
>> >>> > -	int error = -EAGAIN;
>> >>> > +	int error;
>> >>> > +	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 (!strcmp(name, "security.capability")) {
>> >>> > +			error = cap_setxattr_convert_nscap(dentry, value, size,
>> >>> > +					&wvalue, &wsize);
>> >>> > +			if (error < 0)
>> >>> > +				return error;
>> >>> > +			if (wvalue) {
>> >>> > +				value = wvalue;
>> >>> > +				size = wsize;
>> >>> > +			}
>> >>> > +		}
>> >>> > +	}
>> >>> > +
>> >>> > +	error = -EAGAIN;
>> >>> > +
>> >>> 
>> >>> Why is the conversion in __vfs_setxattr_noperm and not in setattr as
>> >>> was done for posix_acl_fix_xattr_from_user?
>> >>
>> >> I think I was thinking I wanted to catch all the vfs_setxattr operations,
>> >> but I don't think that's right.  Moving to setxattr seems right.  I'll
>> >> look around a bit more.
>> >
>> > Thanks.  This is one of these little details that we want a good answer
>> > to why there.  If you can document that in your patch description when
>> > you resend I would appreciate it.
>> 
>> Ok. Grrr.
>> 
>> Looking at this a little more getting it correct where we call the
>> conversion operation is critical. 
>> 
>> I believe the current placement of cap_setxattr_convert_nscap is
>> actively wrong.  In particular unless I am misleading something this
>> will trigger multiple conversions when setting one of these attributes
>> on overlayfs.
>> 
>> The stragey I adopted for for posix acls is:
>> 
>>    On a write from userspace convert from current_user_ns() to &init_user_ns.
>>    On a write to the filesystem convert from &init_user_ns to fs_user_ns.
>>    
>>    On a read from the filesystem convert from fs_user_ns to &init_user_ns
>>    On a read from the kernel to userspace convert from &init_user_ns
>>       to current_user_ns().
>> 
>> Overall a good strategy but no one we can trivially adopt for the
>> capability xattr as the second write to filesystem method does not
>> appear to actually exist for anything except for posix acls.
>> 
>> I need to think a little more about how we want to accomplish this for
>> the capability xattr.  My apoligies for leading you down a path that has
>> all of these bumps and then being sufficiently distracted not to help
>> you through this maze.
>> 
>> The only easy solution I can see is to just always keep things in
>> &init_user_ns inside the kernel.   That works until we bring fuse or
>> other unprivileged mounts onboard that have storage outside of the
>> kernel.
>> 
>> Seth and I will have to rework that for fuse support but that sounds
>> better than not letting such an issue prevent us from merging the code.
>
> Ok, in the meantime I've made a few updates in my tree which I think
> make the code a lot nicer (and do move the conversion to setxattr()),
> but there's a bug in that which I'm still trying to nail down.  I'll
> send a new version when I get that figured, and we can see how close
> to ok that is.
>
> Note that upstream cap_inode_removexattr and cap_inode_setxattr()
> upstream still don't respect the fs_user_ns properly either (the
> proper code is in the Ubuntu kernel, maybe it's in your -next
> tree, I don't know how you and Seth are coordinating that)

Oh yes.  The relaxation of permissions.  I remember holding off
on that until we knew the core vfs work was done.  At this point I don't
think it is necessary to keep holding off.  It seemed prudent before we
got all of the s_user_ns bits used in all of the proper places.

At this point I think it was just worry about the last little vfs bits
has been challenging enough that we just haven't gotten too it.

Eric

  parent reply	other threads:[~2017-04-27 17:00 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-19 16:48 [PATCH] Introduce v3 namespaced file capabilities Serge E. Hallyn
2017-04-19 16:48 ` Serge E. Hallyn
2017-04-19 16:48 ` Serge E. Hallyn
2017-04-21 21:37 ` Eric W. Biederman
2017-04-21 21:37   ` Eric W. Biederman
     [not found]   ` <87a879sarn.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
2017-04-21 21:50     ` Serge E. Hallyn
2017-04-21 21:50       ` Serge E. Hallyn
2017-04-21 21:50       ` Serge E. Hallyn
2017-04-21 21:53       ` Eric W. Biederman
2017-04-21 21:53         ` Eric W. Biederman
     [not found] ` <20170419164824.GA27843-7LNsyQBKDXoIagZqoN9o3w@public.gmane.org>
2017-04-21 23:58   ` Eric W. Biederman
2017-04-21 23:58     ` Eric W. Biederman
2017-04-21 23:58     ` Eric W. Biederman
     [not found]     ` <87wpadpb3m.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
2017-04-22 15:14       ` Serge E. Hallyn
2017-04-22 15:14         ` Serge E. Hallyn
2017-04-22 15:14         ` Serge E. Hallyn
     [not found]         ` <20170422151412.GA14861-7LNsyQBKDXoIagZqoN9o3w@public.gmane.org>
2017-04-23  1:14           ` Eric W. Biederman
2017-04-23  1:14             ` Eric W. Biederman
2017-04-23  1:14             ` Eric W. Biederman
2017-04-27 16:20             ` Eric W. Biederman
2017-04-27 16:20               ` Eric W. Biederman
2017-04-27 16:52               ` Serge E. Hallyn
2017-04-27 16:52                 ` Serge E. Hallyn
     [not found]                 ` <20170427165245.GA794-7LNsyQBKDXoIagZqoN9o3w@public.gmane.org>
2017-04-27 17:00                   ` Eric W. Biederman [this message]
2017-04-27 17:00                     ` Eric W. Biederman
2017-04-27 17:00                     ` Eric W. Biederman

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=874lx9zsye.fsf@xmission.com \
    --to=ebiederm-as9lmozglivwk0htik3j/w@public.gmane.org \
    --cc=agruenba-H+wXaHxf7aLQT0dZR+AlfA@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-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
    --cc=morgan-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
    --cc=serge-A9i7LUbDfNHQT0dZR+AlfA@public.gmane.org \
    --cc=seth.forshee-Z7WLFzj8eWMS+FvcfC7Uqw@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.