Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1538307 > unrolled thread

Re: [PATCH RFC] user-namespaced file capabilities - now with even more magic

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH RFC] user-namespaced file capabilities - now with even more magic ebiederm@xmission.com (Eric W. Biederman) - 2016-12-08 05:50 +0100
    Re: [PATCH RFC] user-namespaced file capabilities - now with even  more magic "Serge E. Hallyn" <serge@hallyn.com> - 2016-12-08 06:00 +0100
      Re: [PATCH RFC] user-namespaced file capabilities - now with even more magic ebiederm@xmission.com (Eric W. Biederman) - 2016-12-08 06:20 +0100
      Re: [PATCH RFC] user-namespaced file capabilities - now with even more magic ebiederm@xmission.com (Eric W. Biederman) - 2016-12-09 09:10 +0100
        Re: [PATCH RFC] user-namespaced file capabilities - now with even  more magic "Serge E. Hallyn" <serge@hallyn.com> - 2016-12-09 14:50 +0100
          Re: [PATCH RFC] user-namespaced file capabilities - now with even more magic ebiederm@xmission.com (Eric W. Biederman) - 2016-12-09 22:50 +0100
            Re: [PATCH RFC] user-namespaced file capabilities - now with even more magic ebiederm@xmission.com (Eric W. Biederman) - 2016-12-10 00:40 +0100

#1538307 — Re: [PATCH RFC] user-namespaced file capabilities - now with even more magic

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

> Root in a user ns cannot be trusted to write a traditional
> security.capability xattr.  If it were allowed to do so, then any
> unprivileged user on the host could map his own uid to root in a
> namespace, write the xattr, and execute the file with privilege on the
> host.
>
> This patch introduces v3 of the security.capability xattr.  It builds a
> vfs_ns_cap_data struct by appending a uid_t rootid to struct
> vfs_cap_data.  This is the absolute uid_t (i.e. the uid_t in
> init_user_ns) of the root id (uid 0 in a namespace) in whose namespaces
> the file capabilities may take effect.
>
> When a task in a user ns (which is privileged with CAP_SETFCAP toward
> that user_ns) asks to write v2 security.capability, the kernel will
> transparently rewrite the xattr as a v3 with the appropriate rootid.
> Subsequently, any task executing the file which has the noted kuid as
> its root uid, or which is in a descendent user_ns of such a user_ns,
> will run the file with capabilities.
>
> If a task writes a v3 security.capability, then it can provide a
> uid (valid within its own user namespace, over which it has CAP_SETFCAP)
> for the xattr.  The kernel will translate that to the absolute uid, and
> write that to disk.  After this, a task in the writer's namespace will
> not be able to use those capabilities, but a task in a namespace where
> the given uid is root will.
>
> Only a single security.capability xattr may be written.  A task may
> overwrite the existing one so long as it was written by a user mapped
> into his own user_ns over which he has CAP_SETFCAP.
>
> This allows a simple setxattr to work, allows tar/untar to work, and
> allows us to tar in one namespace and untar in another while preserving
> the capability, without risking leaking privilege into a parent
> namespace.

Any chance of a singed-off-by?

Eric

[toc] | [next] | [standalone]

#1538312 — Re: [PATCH RFC] user-namespaced file capabilities - now with even more magic

On Thu, Dec 08, 2016 at 05:43:09PM +1300, Eric W. Biederman wrote:
> "Serge E. Hallyn" <serge@hallyn.com> writes:
> 
> > Root in a user ns cannot be trusted to write a traditional
> > security.capability xattr.  If it were allowed to do so, then any
> > unprivileged user on the host could map his own uid to root in a
> > namespace, write the xattr, and execute the file with privilege on the
> > host.
> >
> > This patch introduces v3 of the security.capability xattr.  It builds a
> > vfs_ns_cap_data struct by appending a uid_t rootid to struct
> > vfs_cap_data.  This is the absolute uid_t (i.e. the uid_t in
> > init_user_ns) of the root id (uid 0 in a namespace) in whose namespaces
> > the file capabilities may take effect.
> >
> > When a task in a user ns (which is privileged with CAP_SETFCAP toward
> > that user_ns) asks to write v2 security.capability, the kernel will
> > transparently rewrite the xattr as a v3 with the appropriate rootid.
> > Subsequently, any task executing the file which has the noted kuid as
> > its root uid, or which is in a descendent user_ns of such a user_ns,
> > will run the file with capabilities.
> >
> > If a task writes a v3 security.capability, then it can provide a
> > uid (valid within its own user namespace, over which it has CAP_SETFCAP)
> > for the xattr.  The kernel will translate that to the absolute uid, and
> > write that to disk.  After this, a task in the writer's namespace will
> > not be able to use those capabilities, but a task in a namespace where
> > the given uid is root will.
> >
> > Only a single security.capability xattr may be written.  A task may
> > overwrite the existing one so long as it was written by a user mapped
> > into his own user_ns over which he has CAP_SETFCAP.
> >
> > This allows a simple setxattr to work, allows tar/untar to work, and
> > allows us to tar in one namespace and untar in another while preserving
> > the capability, without risking leaking privilege into a parent
> > namespace.
> 
> Any chance of a singed-off-by?

Yes, sorry, Stéphane had pointed out that I'd apparently forgotten to do
-s.  Do you want me to resend the whole shebang, or does

Signed-off-by: Serge Hallyn <serge@hallyn.com>

suffice?  (My previous iterations did have it fwiw so I don't think I could
legally disavow it now :)

[toc] | [prev] | [next] | [standalone]

#1538320

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

> On Thu, Dec 08, 2016 at 05:43:09PM +1300, Eric W. Biederman wrote:
>> "Serge E. Hallyn" <serge@hallyn.com> writes:
>> 
>> > Root in a user ns cannot be trusted to write a traditional
>> > security.capability xattr.  If it were allowed to do so, then any
>> > unprivileged user on the host could map his own uid to root in a
>> > namespace, write the xattr, and execute the file with privilege on the
>> > host.
>> >
>> > This patch introduces v3 of the security.capability xattr.  It builds a
>> > vfs_ns_cap_data struct by appending a uid_t rootid to struct
>> > vfs_cap_data.  This is the absolute uid_t (i.e. the uid_t in
>> > init_user_ns) of the root id (uid 0 in a namespace) in whose namespaces
>> > the file capabilities may take effect.
>> >
>> > When a task in a user ns (which is privileged with CAP_SETFCAP toward
>> > that user_ns) asks to write v2 security.capability, the kernel will
>> > transparently rewrite the xattr as a v3 with the appropriate rootid.
>> > Subsequently, any task executing the file which has the noted kuid as
>> > its root uid, or which is in a descendent user_ns of such a user_ns,
>> > will run the file with capabilities.
>> >
>> > If a task writes a v3 security.capability, then it can provide a
>> > uid (valid within its own user namespace, over which it has CAP_SETFCAP)
>> > for the xattr.  The kernel will translate that to the absolute uid, and
>> > write that to disk.  After this, a task in the writer's namespace will
>> > not be able to use those capabilities, but a task in a namespace where
>> > the given uid is root will.
>> >
>> > Only a single security.capability xattr may be written.  A task may
>> > overwrite the existing one so long as it was written by a user mapped
>> > into his own user_ns over which he has CAP_SETFCAP.
>> >
>> > This allows a simple setxattr to work, allows tar/untar to work, and
>> > allows us to tar in one namespace and untar in another while preserving
>> > the capability, without risking leaking privilege into a parent
>> > namespace.
>> 
>> Any chance of a singed-off-by?
>
> Yes, sorry, Stéphane had pointed out that I'd apparently forgotten to do
> -s.  Do you want me to resend the whole shebang, or does
>
> Signed-off-by: Serge Hallyn <serge@hallyn.com>
>
> suffice?  (My previous iterations did have it fwiw so I don't think I could
> legally disavow it now :)

That should be good enough.  I just wanted to make certain it existed
somewhere.

The whole inode->i_op->getxattr reference was also a bit of a problem
as that method was removed in 4.9-rc1 but otherwise things are looking
reasonable.

Thank you,
Eric

[toc] | [prev] | [next] | [standalone]

#1539174

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

> On Thu, Dec 08, 2016 at 05:43:09PM +1300, Eric W. Biederman wrote:
>> "Serge E. Hallyn" <serge@hallyn.com> writes:

>> Any chance of a singed-off-by?
>
> Yes, sorry, Stéphane had pointed out that I'd apparently forgotten to do
> -s.  Do you want me to resend the whole shebang, or does
>
> Signed-off-by: Serge Hallyn <serge@hallyn.com>
>
> suffice?  (My previous iterations did have it fwiw so I don't think I could
> legally disavow it now :)

I was really hoping to get this in this for 4.10, but I am seeing a couple
of little things in my review.  Comments referring to a non-existent v4
and a few other niggling little things so I am going to target this for
the next kernel release so there is time review.  With a little luck I
can place this patch in my for-next tree just after the merge window
closes and 4.10-rc1 ships.



Eric

[toc] | [prev] | [next] | [standalone]

#1539357 — Re: [PATCH RFC] user-namespaced file capabilities - now with even more magic

Quoting Eric W. Biederman (ebiederm@xmission.com):
> "Serge E. Hallyn" <serge@hallyn.com> writes:
> 
> > On Thu, Dec 08, 2016 at 05:43:09PM +1300, Eric W. Biederman wrote:
> >> "Serge E. Hallyn" <serge@hallyn.com> writes:
> 
> >> Any chance of a singed-off-by?
> >
> > Yes, sorry, Stéphane had pointed out that I'd apparently forgotten to do
> > -s.  Do you want me to resend the whole shebang, or does
> >
> > Signed-off-by: Serge Hallyn <serge@hallyn.com>
> >
> > suffice?  (My previous iterations did have it fwiw so I don't think I could
> > legally disavow it now :)
> 
> I was really hoping to get this in this for 4.10, but I am seeing a couple
> of little things in my review.  Comments referring to a non-existent v4
> and a few other niggling little things so I am going to target this for
> the next kernel release so there is time review.  With a little luck I
> can place this patch in my for-next tree just after the merge window
> closes and 4.10-rc1 ships.

Ok, thanks.  This is not something I'd want to rush :)

[toc] | [prev] | [next] | [standalone]

#1539700

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

> Quoting Eric W. Biederman (ebiederm@xmission.com):
>> "Serge E. Hallyn" <serge@hallyn.com> writes:
>> 
>> > On Thu, Dec 08, 2016 at 05:43:09PM +1300, Eric W. Biederman wrote:
>> >> "Serge E. Hallyn" <serge@hallyn.com> writes:
>> 
>> >> Any chance of a singed-off-by?
>> >
>> > Yes, sorry, Stéphane had pointed out that I'd apparently forgotten to do
>> > -s.  Do you want me to resend the whole shebang, or does
>> >
>> > Signed-off-by: Serge Hallyn <serge@hallyn.com>
>> >
>> > suffice?  (My previous iterations did have it fwiw so I don't think I could
>> > legally disavow it now :)
>> 
>> I was really hoping to get this in this for 4.10, but I am seeing a couple
>> of little things in my review.  Comments referring to a non-existent v4
>> and a few other niggling little things so I am going to target this for
>> the next kernel release so there is time review.  With a little luck I
>> can place this patch in my for-next tree just after the merge window
>> closes and 4.10-rc1 ships.
>
> Ok, thanks.  This is not something I'd want to rush :)

Sure.  This is just something we get merged.

Eric

[toc] | [prev] | [next] | [standalone]

#1539734

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:
>>> 
>>> > On Thu, Dec 08, 2016 at 05:43:09PM +1300, Eric W. Biederman wrote:
>>> >> "Serge E. Hallyn" <serge@hallyn.com> writes:
>>> 
>>> >> Any chance of a singed-off-by?
>>> >
>>> > Yes, sorry, Stéphane had pointed out that I'd apparently forgotten to do
>>> > -s.  Do you want me to resend the whole shebang, or does
>>> >
>>> > Signed-off-by: Serge Hallyn <serge@hallyn.com>
>>> >
>>> > suffice?  (My previous iterations did have it fwiw so I don't think I could
>>> > legally disavow it now :)
>>> 
>>> I was really hoping to get this in this for 4.10, but I am seeing a couple
>>> of little things in my review.  Comments referring to a non-existent v4
>>> and a few other niggling little things so I am going to target this for
>>> the next kernel release so there is time review.  With a little luck I
>>> can place this patch in my for-next tree just after the merge window
>>> closes and 4.10-rc1 ships.
>>
>> Ok, thanks.  This is not something I'd want to rush :)
>
> Sure.  This is just something we get merged.

By which I meant to say this is something we need to get merged, and
hopefully before all of the developers forget what is going on.  Not
having this is clearly a pain point for people working with file
capabilities.

Eric

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web