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

Groups > linux.kernel > #1672964 > unrolled thread

[PATCH 0/3] Enable namespaced file capabilities

Back to article view | Back to linux.kernel

Contents

  [PATCH 0/3] Enable namespaced file capabilities Stefan Berger <stefanb@linux.vnet.ibm.com> - 2017-06-22 21:10 +0200
    [PATCH 1/3] xattr: Enable security.capability in user namespaces Stefan Berger <stefanb@linux.vnet.ibm.com> - 2017-06-22 21:10 +0200
      [PATCH] xattr: fix kstrdup.cocci warnings kbuild test robot <lkp@intel.com> - 2017-06-24 23:10 +0200
      Re: [PATCH 1/3] xattr: Enable security.capability in user namespaces kbuild test robot <lkp@intel.com> - 2017-06-24 23:10 +0200
    Re: [PATCH 0/3] Enable namespaced file capabilities Casey Schaufler <casey@schaufler-ca.com> - 2017-06-22 22:00 +0200
      Re: [PATCH 0/3] Enable namespaced file capabilities Stefan Berger <stefanb@linux.vnet.ibm.com> - 2017-06-22 22:20 +0200
        Re: [PATCH 0/3] Enable namespaced file capabilities Casey Schaufler <casey@schaufler-ca.com> - 2017-06-22 22:40 +0200
          Re: [PATCH 0/3] Enable namespaced file capabilities Stefan Berger <stefanb@linux.vnet.ibm.com> - 2017-06-22 23:10 +0200
          Re: [PATCH 0/3] Enable namespaced file capabilities "Serge E. Hallyn" <serge@hallyn.com> - 2017-06-22 23:10 +0200
            Re: [PATCH 0/3] Enable namespaced file capabilities Casey Schaufler <casey@schaufler-ca.com> - 2017-06-23 00:50 +0200
              Re: [PATCH 0/3] Enable namespaced file capabilities "Serge E. Hallyn" <serge@hallyn.com> - 2017-06-23 01:10 +0200
    Re: [PATCH 0/3] Enable namespaced file capabilities "Serge E. Hallyn" <serge@hallyn.com> - 2017-06-23 01:40 +0200
      Re: [PATCH 0/3] Enable namespaced file capabilities James Bottomley <James.Bottomley@HansenPartnership.com> - 2017-06-23 02:20 +0200
        Re: [PATCH 0/3] Enable namespaced file capabilities "Serge E. Hallyn" <serge@hallyn.com> - 2017-06-23 03:30 +0200
        Re: [PATCH 0/3] Enable namespaced file capabilities ebiederm@xmission.com (Eric W. Biederman) - 2017-06-23 19:50 +0200
          Re: [PATCH 0/3] Enable namespaced file capabilities "Serge E. Hallyn" <serge@hallyn.com> - 2017-06-23 20:40 +0200
    Re: [PATCH 0/3] Enable namespaced file capabilities "Serge E. Hallyn" <serge@hallyn.com> - 2017-06-23 01:40 +0200
    Re: [PATCH 0/3] Enable namespaced file capabilities James Bottomley <James.Bottomley@HansenPartnership.com> - 2017-06-23 01:40 +0200
    Re: [PATCH 0/3] Enable namespaced file capabilities Amir Goldstein <amir73il@gmail.com> - 2017-06-23 09:10 +0200
      Re: [PATCH 0/3] Enable namespaced file capabilities "Serge E. Hallyn" <serge@hallyn.com> - 2017-06-23 18:10 +0200
        Re: [PATCH 0/3] Enable namespaced file capabilities Casey Schaufler <casey@schaufler-ca.com> - 2017-06-23 18:20 +0200
          Re: [PATCH 0/3] Enable namespaced file capabilities "Serge E. Hallyn" <serge@hallyn.com> - 2017-06-23 18:40 +0200
            Re: [PATCH 0/3] Enable namespaced file capabilities Casey Schaufler <casey@schaufler-ca.com> - 2017-06-23 19:00 +0200
              Re: [PATCH 0/3] Enable namespaced file capabilities "Serge E. Hallyn" <serge@hallyn.com> - 2017-06-23 19:10 +0200
                Re: [PATCH 0/3] Enable namespaced file capabilities ebiederm@xmission.com (Eric W. Biederman) - 2017-06-23 20:00 +0200
                  Re: [PATCH 0/3] Enable namespaced file capabilities "Serge E. Hallyn" <serge@hallyn.com> - 2017-06-23 20:40 +0200
            Re: [PATCH 0/3] Enable namespaced file capabilities James Bottomley <James.Bottomley@HansenPartnership.com> - 2017-06-23 19:10 +0200
              Re: [PATCH 0/3] Enable namespaced file capabilities "Serge E. Hallyn" <serge@hallyn.com> - 2017-06-23 19:30 +0200
              Re: [PATCH 0/3] Enable namespaced file capabilities Stefan Berger <stefanb@linux.vnet.ibm.com> - 2017-06-23 19:40 +0200
                Re: [PATCH 0/3] Enable namespaced file capabilities "Serge E. Hallyn" <serge@hallyn.com> - 2017-06-23 20:40 +0200
          Re: [PATCH 0/3] Enable namespaced file capabilities Stefan Berger <stefanb@linux.vnet.ibm.com> - 2017-06-23 20:10 +0200
            Re: [PATCH 0/3] Enable namespaced file capabilities "Serge E. Hallyn" <serge@hallyn.com> - 2017-06-23 20:40 +0200
              Re: [PATCH 0/3] Enable namespaced file capabilities Casey Schaufler <casey@schaufler-ca.com> - 2017-06-23 22:40 +0200
              Re: [PATCH 0/3] Enable namespaced file capabilities Stefan Berger <stefanb@linux.vnet.ibm.com> - 2017-06-24 01:10 +0200
                Re: [PATCH 0/3] Enable namespaced file capabilities Casey Schaufler <casey@schaufler-ca.com> - 2017-06-24 02:00 +0200
      Re: [PATCH 0/3] Enable namespaced file capabilities "Serge E. Hallyn" <serge@hallyn.com> - 2017-06-28 07:50 +0200
        Re: [PATCH 0/3] Enable namespaced file capabilities Amir Goldstein <amir73il@gmail.com> - 2017-06-28 09:20 +0200
          Re: [PATCH 0/3] Enable namespaced file capabilities Stefan Berger <stefanb@linux.vnet.ibm.com> - 2017-06-28 16:10 +0200
          Re: [PATCH 0/3] Enable namespaced file capabilities "Serge E. Hallyn" <serge@hallyn.com> - 2017-06-28 16:30 +0200
    Re: [PATCH 0/3] Enable namespaced file capabilities Vivek Goyal <vgoyal@redhat.com> - 2017-06-23 22:20 +0200
      Re: [PATCH 0/3] Enable namespaced file capabilities "Serge E. Hallyn" <serge@hallyn.com> - 2017-06-23 22:20 +0200
        Re: [PATCH 0/3] Enable namespaced file capabilities Vivek Goyal <vgoyal@redhat.com> - 2017-06-23 22:40 +0200
          Re: [PATCH 0/3] Enable namespaced file capabilities "Serge E. Hallyn" <serge@hallyn.com> - 2017-06-23 23:00 +0200

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#1673662

On 6/23/2017 9:00 AM, Serge E. Hallyn wrote:
> Quoting Amir Goldstein (amir73il@gmail.com):
>> On Thu, Jun 22, 2017 at 9:59 PM, Stefan Berger
>> <stefanb@linux.vnet.ibm.com> wrote:
>>> This series of patches primary goal is to enable file capabilities
>>> in user namespaces without affecting the file capabilities that are
>>> effective on the host. This is to prevent that any unprivileged user
>>> on the host maps his own uid to root in a private namespace, writes
>>> the xattr, and executes the file with privilege on the host.
>>>
>>> We achieve this goal by writing extended attributes with a different
>>> name when a user namespace is used. If for example the root user
>>> in a user namespace writes the security.capability xattr, the name
>>> of the xattr that is actually written is encoded as
>>> security.capability@uid=1000 for root mapped to uid 1000 on the host.
>>> When listing the xattrs on the host, the existing security.capability
>>> as well as the security.capability@uid=1000 will be shown. Inside the
>>> namespace only 'security.capability', with the value of
>>> security.capability@uid=1000, is visible.
>>>
>> Am I the only one who thinks that suffix is perhaps not the best grammar
>> to use for this namespace?
> You're the only one to have mentioned it so far.
>
>> xattrs are clearly namespaced by prefix, so it seems right to me to keep
>> it that way - define a new special xattr namespace "ns" and only if that
>> prefix exists, the @uid suffix will be parsed.
>> This could be either  ns.security.capability@uid=1000 or
>> ns@uid=1000.security.capability. The latter seems more correct to me,
>> because then we will be able to namespace any xattr without having to
>> protect from "unprivileged xattr injection", i.e.:
>> setfattr -n "user.whatever.foo@uid=0"
> I like it for simplifying the parser code.  One concern I have is that,
> since ns.* is currently not gated, one could write ns.* on an older
> kernel and then exploit it on a newer one.

security.ns.capability@uid=1000, then?

Or maybe just security.ns.capability, taking James' comment into account.

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

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

#1673676

Quoting Casey Schaufler (casey@schaufler-ca.com):
> On 6/23/2017 9:00 AM, Serge E. Hallyn wrote:
> > Quoting Amir Goldstein (amir73il@gmail.com):
> >> On Thu, Jun 22, 2017 at 9:59 PM, Stefan Berger
> >> <stefanb@linux.vnet.ibm.com> wrote:
> >>> This series of patches primary goal is to enable file capabilities
> >>> in user namespaces without affecting the file capabilities that are
> >>> effective on the host. This is to prevent that any unprivileged user
> >>> on the host maps his own uid to root in a private namespace, writes
> >>> the xattr, and executes the file with privilege on the host.
> >>>
> >>> We achieve this goal by writing extended attributes with a different
> >>> name when a user namespace is used. If for example the root user
> >>> in a user namespace writes the security.capability xattr, the name
> >>> of the xattr that is actually written is encoded as
> >>> security.capability@uid=1000 for root mapped to uid 1000 on the host.
> >>> When listing the xattrs on the host, the existing security.capability
> >>> as well as the security.capability@uid=1000 will be shown. Inside the
> >>> namespace only 'security.capability', with the value of
> >>> security.capability@uid=1000, is visible.
> >>>
> >> Am I the only one who thinks that suffix is perhaps not the best grammar
> >> to use for this namespace?
> > You're the only one to have mentioned it so far.
> >
> >> xattrs are clearly namespaced by prefix, so it seems right to me to keep
> >> it that way - define a new special xattr namespace "ns" and only if that
> >> prefix exists, the @uid suffix will be parsed.
> >> This could be either  ns.security.capability@uid=1000 or
> >> ns@uid=1000.security.capability. The latter seems more correct to me,
> >> because then we will be able to namespace any xattr without having to
> >> protect from "unprivileged xattr injection", i.e.:
> >> setfattr -n "user.whatever.foo@uid=0"
> > I like it for simplifying the parser code.  One concern I have is that,
> > since ns.* is currently not gated, one could write ns.* on an older
> > kernel and then exploit it on a newer one.
> 
> security.ns.capability@uid=1000, then?

That loses the advantage of simpler parsing though.  (Really it's not much
of a simplification anyway.)  So I'm not sure what advantage remains.

> Or maybe just security.ns.capability, taking James' comment into account.

That last one may be suitable as an option, useful for his particular
(somewhat barbaric :) use case, but it's not ok for the general solution.

If uid 1000 was delegated the subuids 100000-199999, it should be able
to write a file capability for use by his subuids, but that file capability
must not apply to other subuids.

-serge

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

#1673682

On 6/23/2017 9:30 AM, Serge E. Hallyn wrote:
> Quoting Casey Schaufler (casey@schaufler-ca.com):
>> On 6/23/2017 9:00 AM, Serge E. Hallyn wrote:
>>> Quoting Amir Goldstein (amir73il@gmail.com):
>>>> On Thu, Jun 22, 2017 at 9:59 PM, Stefan Berger
>>>> <stefanb@linux.vnet.ibm.com> wrote:
>>>>> This series of patches primary goal is to enable file capabilities
>>>>> in user namespaces without affecting the file capabilities that are
>>>>> effective on the host. This is to prevent that any unprivileged user
>>>>> on the host maps his own uid to root in a private namespace, writes
>>>>> the xattr, and executes the file with privilege on the host.
>>>>>
>>>>> We achieve this goal by writing extended attributes with a different
>>>>> name when a user namespace is used. If for example the root user
>>>>> in a user namespace writes the security.capability xattr, the name
>>>>> of the xattr that is actually written is encoded as
>>>>> security.capability@uid=1000 for root mapped to uid 1000 on the host.
>>>>> When listing the xattrs on the host, the existing security.capability
>>>>> as well as the security.capability@uid=1000 will be shown. Inside the
>>>>> namespace only 'security.capability', with the value of
>>>>> security.capability@uid=1000, is visible.
>>>>>
>>>> Am I the only one who thinks that suffix is perhaps not the best grammar
>>>> to use for this namespace?
>>> You're the only one to have mentioned it so far.
>>>
>>>> xattrs are clearly namespaced by prefix, so it seems right to me to keep
>>>> it that way - define a new special xattr namespace "ns" and only if that
>>>> prefix exists, the @uid suffix will be parsed.
>>>> This could be either  ns.security.capability@uid=1000 or
>>>> ns@uid=1000.security.capability. The latter seems more correct to me,
>>>> because then we will be able to namespace any xattr without having to
>>>> protect from "unprivileged xattr injection", i.e.:
>>>> setfattr -n "user.whatever.foo@uid=0"
>>> I like it for simplifying the parser code.  One concern I have is that,
>>> since ns.* is currently not gated, one could write ns.* on an older
>>> kernel and then exploit it on a newer one.
>> security.ns.capability@uid=1000, then?
> That loses the advantage of simpler parsing though.  (Really it's not much
> of a simplification anyway.)  So I'm not sure what advantage remains.
>
>> Or maybe just security.ns.capability, taking James' comment into account.
> That last one may be suitable as an option, useful for his particular
> (somewhat barbaric :) use case, but it's not ok for the general solution.

security.ns@uid=100.capability

It makes the namespace part explicit and separate from
the rest of the attribute name. It also generalizes for
other attributes.

security.ns@uid=1000@smack=WestOfOne.SMACK64

> If uid 1000 was delegated the subuids 100000-199999, it should be able
> to write a file capability for use by his subuids, but that file capability
> must not apply to other subuids.
>
> -serge
>

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

#1673691

Quoting Casey Schaufler (casey@schaufler-ca.com):
> On 6/23/2017 9:30 AM, Serge E. Hallyn wrote:
> > Quoting Casey Schaufler (casey@schaufler-ca.com):
> >> Or maybe just security.ns.capability, taking James' comment into account.
> > That last one may be suitable as an option, useful for his particular
> > (somewhat barbaric :) use case, but it's not ok for the general solution.
> 
> security.ns@uid=100.capability

I'm ok with this.  It gives protection from older kernels, and puts
the 'ns@uid=' at predictable locations for security and trusted.

> It makes the namespace part explicit and separate from
> the rest of the attribute name. It also generalizes for
> other attributes.
> 
> security.ns@uid=1000@smack=WestOfOne.SMACK64

Looks good to me.

Do we want to say that '.' ends the attribute list?  That of
course means '.' cannot be in the attributes.  Perhaps end
with '@@' instead?  Just a thought.

What do others think?

thanks,
-serge

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

#1673734

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

> Quoting Casey Schaufler (casey@schaufler-ca.com):
>> On 6/23/2017 9:30 AM, Serge E. Hallyn wrote:
>> > Quoting Casey Schaufler (casey@schaufler-ca.com):
>> >> Or maybe just security.ns.capability, taking James' comment into account.
>> > That last one may be suitable as an option, useful for his particular
>> > (somewhat barbaric :) use case, but it's not ok for the general solution.
>> 
>> security.ns@uid=100.capability
>
> I'm ok with this.  It gives protection from older kernels, and puts
> the 'ns@uid=' at predictable locations for security and trusted.
>
>> It makes the namespace part explicit and separate from
>> the rest of the attribute name. It also generalizes for
>> other attributes.
>> 
>> security.ns@uid=1000@smack=WestOfOne.SMACK64
>
> Looks good to me.
>
> Do we want to say that '.' ends the attribute list?  That of
> course means '.' cannot be in the attributes.  Perhaps end
> with '@@' instead?  Just a thought.
>
> What do others think?

I think we have two things that will limit the allowed attributes
severely.

1) We need to the names of all of the xattrs when mounting a filesystem
   with s_user_ns != &init_user_ns.  I haven't yet checked the patches
   to see if they do this properly.

2) Names of xattrs are not fully general and filesystems perform various
   tricks to encode them more densely.  We should see what the games
   with xattr names do to how densely xattrs can be stored on disk.
   That matters.

Putting the uid of the root user in the name sounds fundamental to doing
things this way.  I am not at all certain about putting smack labels and
generally treating this as something we can add two arbitrarily.

If nothing else this reminds me of the frequent problem in
certifications with ouids.  Arbitrary attributes tend to defeat parsers
in a security context on a regular basis.  Even the kernel command line
parser has seen problems in this area, and it isn't security sensitive
most of the time.

Extensibility is good in the abstract long term sense.  Extensibility in
the here and now where we don't even know which attributes we are
talking about scares me.  I don't see how we can possibily know with
multiple attributes which xattrs will be the one to use.  As we won't
even know which properties of the kernel to look at to match attributes.

So while I don't mind reorganizing the order we put the information into
the attribute.  Let's keep what we place in there very specific.

Eric

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

#1673767

Quoting Eric W. Biederman (ebiederm@xmission.com):
> "Serge E. Hallyn" <serge@hallyn.com> writes:
> 
> > Quoting Casey Schaufler (casey@schaufler-ca.com):
> >> On 6/23/2017 9:30 AM, Serge E. Hallyn wrote:
> >> > Quoting Casey Schaufler (casey@schaufler-ca.com):
> >> >> Or maybe just security.ns.capability, taking James' comment into account.
> >> > That last one may be suitable as an option, useful for his particular
> >> > (somewhat barbaric :) use case, but it's not ok for the general solution.
> >> 
> >> security.ns@uid=100.capability
> >
> > I'm ok with this.  It gives protection from older kernels, and puts
> > the 'ns@uid=' at predictable locations for security and trusted.
> >
> >> It makes the namespace part explicit and separate from
> >> the rest of the attribute name. It also generalizes for
> >> other attributes.
> >> 
> >> security.ns@uid=1000@smack=WestOfOne.SMACK64
> >
> > Looks good to me.
> >
> > Do we want to say that '.' ends the attribute list?  That of
> > course means '.' cannot be in the attributes.  Perhaps end
> > with '@@' instead?  Just a thought.
> >
> > What do others think?
> 
> I think we have two things that will limit the allowed attributes
> severely.
> 
> 1) We need to the names of all of the xattrs when mounting a filesystem
>    with s_user_ns != &init_user_ns.  I haven't yet checked the patches
>    to see if they do this properly.
> 
> 2) Names of xattrs are not fully general and filesystems perform various
>    tricks to encode them more densely.  We should see what the games
>    with xattr names do to how densely xattrs can be stored on disk.
>    That matters.
> 
> Putting the uid of the root user in the name sounds fundamental to doing
> things this way.  I am not at all certain about putting smack labels and
> generally treating this as something we can add two arbitrarily.
> 
> If nothing else this reminds me of the frequent problem in
> certifications with ouids.  Arbitrary attributes tend to defeat parsers
> in a security context on a regular basis.  Even the kernel command line
> parser has seen problems in this area, and it isn't security sensitive
> most of the time.
> 
> Extensibility is good in the abstract long term sense.  Extensibility in
> the here and now where we don't even know which attributes we are
> talking about scares me.  I don't see how we can possibily know with
> multiple attributes which xattrs will be the one to use.  As we won't
> even know which properties of the kernel to look at to match attributes.
> 
> So while I don't mind reorganizing the order we put the information into
> the attribute.  Let's keep what we place in there very specific.

Right.  I'm in favor of making the syntax so that it is, in the future,
if we want it to be, extensible, but we would not be accepting generic
attributes now.

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

#1673696

On Fri, 2017-06-23 at 11:30 -0500, Serge E. Hallyn wrote:
> Quoting Casey Schaufler (casey@schaufler-ca.com):
> > Or maybe just security.ns.capability, taking James' comment into
> > account.
> 
> That last one may be suitable as an option, useful for his particular
> (somewhat barbaric :) use case, but it's not ok for the general
> solution.
> 
> If uid 1000 was delegated the subuids 100000-199999, it should be 
> able to write a file capability for use by his subuids, but that file
> capability must not apply to other subuids.

I don't think it's barbaric, I think it's the common use case.  Let me
give a more comprehensible answer in terms of docker and IMA.  Lets
suppose I'm running docker locally and in a test cloud both with userns
enabled.

I build an image locally, mapping my uid (1000) to root.  If I begin
with a standard base, each of the files has a security.ima signature. 
 Now I add my layer, which involves updating a file, so I need to write
a new signature to security.ima.  Because I'm running user namespaced,
the update gets written at security.ima@uid=1000 when I do a docker
save. 

Now supposing I deploy that image to a cloud.  As a tenant, the cloud
gives me real uid 4531 and maps that to root.  Execution of the binary
fails because it tries to use the underlying signature (in
security.ima) as there is no xattr named security.ima@uid=4531

So my essential point is that building the real kuid into the permanent
record of the xattr damages image portability, which is touted as one
of the real advantages of container images.

James

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

#1673702

Quoting James Bottomley (James.Bottomley@HansenPartnership.com):
> On Fri, 2017-06-23 at 11:30 -0500, Serge E. Hallyn wrote:
> > Quoting Casey Schaufler (casey@schaufler-ca.com):
> > > Or maybe just security.ns.capability, taking James' comment into
> > > account.
> > 
> > That last one may be suitable as an option, useful for his particular
> > (somewhat barbaric :) use case, but it's not ok for the general
> > solution.
> > 
> > If uid 1000 was delegated the subuids 100000-199999, it should be 
> > able to write a file capability for use by his subuids, but that file
> > capability must not apply to other subuids.
> 
> I don't think it's barbaric, I think it's the common use case.  Let me

:)  sorry.  Yes, it is the common case, and even lxd does it that way.
But lxc itself does not, and while there are shortcomings (including
this one, file capabilities) which require 'barbaric' use of privilege
to set things up in some cases, I prefer we not get complacent and accept
it as proper.

> give a more comprehensible answer in terms of docker and IMA.  Lets
> suppose I'm running docker locally and in a test cloud both with userns
> enabled.
> 
> I build an image locally, mapping my uid (1000) to root.  If I begin
> with a standard base, each of the files has a security.ima signature. 
>  Now I add my layer, which involves updating a file, so I need to write
> a new signature to security.ima.  Because I'm running user namespaced,
> the update gets written at security.ima@uid=1000 when I do a docker
> save. 
> 
> Now supposing I deploy that image to a cloud.  As a tenant, the cloud
> gives me real uid 4531 and maps that to root.  Execution of the binary
> fails because it tries to use the underlying signature (in
> security.ima) as there is no xattr named security.ima@uid=4531

In this example, how do you, if you do, shift the owner of the file
into the mapped user namespace?  Or are you happy to have the file owned
by an invalid user nobody?  (There certainly are cases where that would
be ok, but I suspect you're shifting the file)

> So my essential point is that building the real kuid into the permanent
> record of the xattr damages image portability, which is touted as one
> of the real advantages of container images.

'container images' aren't portable in that sense now - for at least
many cases - because you have to shift the uid.  However you're doing
that, you may be able to shift the xattr the same way.

-serge

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

#1673706

On 06/23/2017 01:07 PM, James Bottomley wrote:
> On Fri, 2017-06-23 at 11:30 -0500, Serge E. Hallyn wrote:
>> Quoting Casey Schaufler (casey@schaufler-ca.com):
>>> Or maybe just security.ns.capability, taking James' comment into
>>> account.
>> That last one may be suitable as an option, useful for his particular
>> (somewhat barbaric :) use case, but it's not ok for the general
>> solution.
>>
>> If uid 1000 was delegated the subuids 100000-199999, it should be
>> able to write a file capability for use by his subuids, but that file
>> capability must not apply to other subuids.
> I don't think it's barbaric, I think it's the common use case.  Let me
> give a more comprehensible answer in terms of docker and IMA.  Lets
> suppose I'm running docker locally and in a test cloud both with userns
> enabled.
>
> I build an image locally, mapping my uid (1000) to root.  If I begin
> with a standard base, each of the files has a security.ima signature.
>   Now I add my layer, which involves updating a file, so I need to write
> a new signature to security.ima.  Because I'm running user namespaced,
> the update gets written at security.ima@uid=1000 when I do a docker
> save.
>
> Now supposing I deploy that image to a cloud.  As a tenant, the cloud
> gives me real uid 4531 and maps that to root.  Execution of the binary
> fails because it tries to use the underlying signature (in
> security.ima) as there is no xattr named security.ima@uid=4531

Yes. An answer would be to have Docker rewrite these on the fly. It 
knows what uid the container was running as and specifically looks for 
security.ima@uid=1000 or security.ima, takes the former if it finds, 
otherwise the latter or nothing.

    Stefan

>
> So my essential point is that building the real kuid into the permanent
> record of the xattr damages image portability, which is touted as one
> of the real advantages of container images.
>
> James
>

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

#1673762

Quoting Stefan Berger (stefanb@linux.vnet.ibm.com):
> On 06/23/2017 01:07 PM, James Bottomley wrote:
> >On Fri, 2017-06-23 at 11:30 -0500, Serge E. Hallyn wrote:
> >>Quoting Casey Schaufler (casey@schaufler-ca.com):
> >>>Or maybe just security.ns.capability, taking James' comment into
> >>>account.
> >>That last one may be suitable as an option, useful for his particular
> >>(somewhat barbaric :) use case, but it's not ok for the general
> >>solution.
> >>
> >>If uid 1000 was delegated the subuids 100000-199999, it should be
> >>able to write a file capability for use by his subuids, but that file
> >>capability must not apply to other subuids.
> >I don't think it's barbaric, I think it's the common use case.  Let me
> >give a more comprehensible answer in terms of docker and IMA.  Lets
> >suppose I'm running docker locally and in a test cloud both with userns
> >enabled.
> >
> >I build an image locally, mapping my uid (1000) to root.  If I begin
> >with a standard base, each of the files has a security.ima signature.
> >  Now I add my layer, which involves updating a file, so I need to write
> >a new signature to security.ima.  Because I'm running user namespaced,
> >the update gets written at security.ima@uid=1000 when I do a docker
> >save.
> >
> >Now supposing I deploy that image to a cloud.  As a tenant, the cloud
> >gives me real uid 4531 and maps that to root.  Execution of the binary
> >fails because it tries to use the underlying signature (in
> >security.ima) as there is no xattr named security.ima@uid=4531
> 
> Yes. An answer would be to have Docker rewrite these on the fly. It
> knows what uid the container was running as and specifically looks
> for security.ima@uid=1000 or security.ima, takes the former if it
> finds, otherwise the latter or nothing.

I know many people hate this answer, but I just want to point out that
on my little laptop, while untarring a 500M images takes 9.5 seconds,
remapping all uids and gids and restoring setuid+setgid on that image
takes .01s.

It's high cpu utilization, and it's not zero time, but it's very fast,
and it's 100% safe (when done the right way, not "sudo domychown").

-serge

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

#1673746

On 06/23/2017 12:16 PM, Casey Schaufler wrote:
> On 6/23/2017 9:00 AM, Serge E. Hallyn wrote:
>> Quoting Amir Goldstein (amir73il@gmail.com):
>>> On Thu, Jun 22, 2017 at 9:59 PM, Stefan Berger
>>> <stefanb@linux.vnet.ibm.com> wrote:
>>>> This series of patches primary goal is to enable file capabilities
>>>> in user namespaces without affecting the file capabilities that are
>>>> effective on the host. This is to prevent that any unprivileged user
>>>> on the host maps his own uid to root in a private namespace, writes
>>>> the xattr, and executes the file with privilege on the host.
>>>>
>>>> We achieve this goal by writing extended attributes with a different
>>>> name when a user namespace is used. If for example the root user
>>>> in a user namespace writes the security.capability xattr, the name
>>>> of the xattr that is actually written is encoded as
>>>> security.capability@uid=1000 for root mapped to uid 1000 on the host.
>>>> When listing the xattrs on the host, the existing security.capability
>>>> as well as the security.capability@uid=1000 will be shown. Inside the
>>>> namespace only 'security.capability', with the value of
>>>> security.capability@uid=1000, is visible.
>>>>
>>> Am I the only one who thinks that suffix is perhaps not the best grammar
>>> to use for this namespace?
>> You're the only one to have mentioned it so far.
>>
>>> xattrs are clearly namespaced by prefix, so it seems right to me to keep
>>> it that way - define a new special xattr namespace "ns" and only if that
>>> prefix exists, the @uid suffix will be parsed.
>>> This could be either  ns.security.capability@uid=1000 or
>>> ns@uid=1000.security.capability. The latter seems more correct to me,
>>> because then we will be able to namespace any xattr without having to
>>> protect from "unprivileged xattr injection", i.e.:
>>> setfattr -n "user.whatever.foo@uid=0"
>> I like it for simplifying the parser code.  One concern I have is that,
>> since ns.* is currently not gated, one could write ns.* on an older
>> kernel and then exploit it on a newer one.
> security.ns.capability@uid=1000, then?

Imo, '.ns' is redundant and 'encoded' in the '@'.

    Stefan

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

#1673765

Quoting Stefan Berger (stefanb@linux.vnet.ibm.com):
> On 06/23/2017 12:16 PM, Casey Schaufler wrote:
> >On 6/23/2017 9:00 AM, Serge E. Hallyn wrote:
> >>Quoting Amir Goldstein (amir73il@gmail.com):
> >>>On Thu, Jun 22, 2017 at 9:59 PM, Stefan Berger
> >>><stefanb@linux.vnet.ibm.com> wrote:
> >>>>This series of patches primary goal is to enable file capabilities
> >>>>in user namespaces without affecting the file capabilities that are
> >>>>effective on the host. This is to prevent that any unprivileged user
> >>>>on the host maps his own uid to root in a private namespace, writes
> >>>>the xattr, and executes the file with privilege on the host.
> >>>>
> >>>>We achieve this goal by writing extended attributes with a different
> >>>>name when a user namespace is used. If for example the root user
> >>>>in a user namespace writes the security.capability xattr, the name
> >>>>of the xattr that is actually written is encoded as
> >>>>security.capability@uid=1000 for root mapped to uid 1000 on the host.
> >>>>When listing the xattrs on the host, the existing security.capability
> >>>>as well as the security.capability@uid=1000 will be shown. Inside the
> >>>>namespace only 'security.capability', with the value of
> >>>>security.capability@uid=1000, is visible.
> >>>>
> >>>Am I the only one who thinks that suffix is perhaps not the best grammar
> >>>to use for this namespace?
> >>You're the only one to have mentioned it so far.
> >>
> >>>xattrs are clearly namespaced by prefix, so it seems right to me to keep
> >>>it that way - define a new special xattr namespace "ns" and only if that
> >>>prefix exists, the @uid suffix will be parsed.
> >>>This could be either  ns.security.capability@uid=1000 or
> >>>ns@uid=1000.security.capability. The latter seems more correct to me,
> >>>because then we will be able to namespace any xattr without having to
> >>>protect from "unprivileged xattr injection", i.e.:
> >>>setfattr -n "user.whatever.foo@uid=0"
> >>I like it for simplifying the parser code.  One concern I have is that,
> >>since ns.* is currently not gated, one could write ns.* on an older
> >>kernel and then exploit it on a newer one.
> >security.ns.capability@uid=1000, then?
> 
> Imo, '.ns' is redundant and 'encoded' in the '@'.

So how about
	security.@uid=1000@@capability ?

Maybe it's not worth it.

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

#1673854

On 6/23/2017 11:35 AM, Serge E. Hallyn wrote:
> Quoting Stefan Berger (stefanb@linux.vnet.ibm.com):
>> On 06/23/2017 12:16 PM, Casey Schaufler wrote:
>>> On 6/23/2017 9:00 AM, Serge E. Hallyn wrote:
>>>> Quoting Amir Goldstein (amir73il@gmail.com):
>>>>> On Thu, Jun 22, 2017 at 9:59 PM, Stefan Berger
>>>>> <stefanb@linux.vnet.ibm.com> wrote:
>>>>>> This series of patches primary goal is to enable file capabilities
>>>>>> in user namespaces without affecting the file capabilities that are
>>>>>> effective on the host. This is to prevent that any unprivileged user
>>>>>> on the host maps his own uid to root in a private namespace, writes
>>>>>> the xattr, and executes the file with privilege on the host.
>>>>>>
>>>>>> We achieve this goal by writing extended attributes with a different
>>>>>> name when a user namespace is used. If for example the root user
>>>>>> in a user namespace writes the security.capability xattr, the name
>>>>>> of the xattr that is actually written is encoded as
>>>>>> security.capability@uid=1000 for root mapped to uid 1000 on the host.
>>>>>> When listing the xattrs on the host, the existing security.capability
>>>>>> as well as the security.capability@uid=1000 will be shown. Inside the
>>>>>> namespace only 'security.capability', with the value of
>>>>>> security.capability@uid=1000, is visible.
>>>>>>
>>>>> Am I the only one who thinks that suffix is perhaps not the best grammar
>>>>> to use for this namespace?
>>>> You're the only one to have mentioned it so far.
>>>>
>>>>> xattrs are clearly namespaced by prefix, so it seems right to me to keep
>>>>> it that way - define a new special xattr namespace "ns" and only if that
>>>>> prefix exists, the @uid suffix will be parsed.
>>>>> This could be either  ns.security.capability@uid=1000 or
>>>>> ns@uid=1000.security.capability. The latter seems more correct to me,
>>>>> because then we will be able to namespace any xattr without having to
>>>>> protect from "unprivileged xattr injection", i.e.:
>>>>> setfattr -n "user.whatever.foo@uid=0"
>>>> I like it for simplifying the parser code.  One concern I have is that,
>>>> since ns.* is currently not gated, one could write ns.* on an older
>>>> kernel and then exploit it on a newer one.
>>> security.ns.capability@uid=1000, then?
>> Imo, '.ns' is redundant and 'encoded' in the '@'.
> So how about
> 	security.@uid=1000@@capability ?

You're back to messing up the final component of the
attribute name. If you want a namespace component, keep
it separate. I disagree with the ".ns" being redundant.
It's descriptive.

	security.ns@uid=1000@@.capability.

looks right to me.

>
> Maybe it's not worth it.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

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

#1673936

On 06/23/2017 02:35 PM, Serge E. Hallyn wrote:
> Quoting Stefan Berger (stefanb@linux.vnet.ibm.com):
>> On 06/23/2017 12:16 PM, Casey Schaufler wrote:
>>> On 6/23/2017 9:00 AM, Serge E. Hallyn wrote:
>>>> Quoting Amir Goldstein (amir73il@gmail.com):
>>>>> On Thu, Jun 22, 2017 at 9:59 PM, Stefan Berger
>>>>> <stefanb@linux.vnet.ibm.com> wrote:
>>>>>> This series of patches primary goal is to enable file capabilities
>>>>>> in user namespaces without affecting the file capabilities that are
>>>>>> effective on the host. This is to prevent that any unprivileged user
>>>>>> on the host maps his own uid to root in a private namespace, writes
>>>>>> the xattr, and executes the file with privilege on the host.
>>>>>>
>>>>>> We achieve this goal by writing extended attributes with a different
>>>>>> name when a user namespace is used. If for example the root user
>>>>>> in a user namespace writes the security.capability xattr, the name
>>>>>> of the xattr that is actually written is encoded as
>>>>>> security.capability@uid=1000 for root mapped to uid 1000 on the host.
>>>>>> When listing the xattrs on the host, the existing security.capability
>>>>>> as well as the security.capability@uid=1000 will be shown. Inside the
>>>>>> namespace only 'security.capability', with the value of
>>>>>> security.capability@uid=1000, is visible.
>>>>>>
>>>>> Am I the only one who thinks that suffix is perhaps not the best grammar
>>>>> to use for this namespace?
>>>> You're the only one to have mentioned it so far.
>>>>
>>>>> xattrs are clearly namespaced by prefix, so it seems right to me to keep
>>>>> it that way - define a new special xattr namespace "ns" and only if that
>>>>> prefix exists, the @uid suffix will be parsed.
>>>>> This could be either  ns.security.capability@uid=1000 or
>>>>> ns@uid=1000.security.capability. The latter seems more correct to me,
>>>>> because then we will be able to namespace any xattr without having to
>>>>> protect from "unprivileged xattr injection", i.e.:
>>>>> setfattr -n "user.whatever.foo@uid=0"
>>>> I like it for simplifying the parser code.  One concern I have is that,
>>>> since ns.* is currently not gated, one could write ns.* on an older
>>>> kernel and then exploit it on a newer one.
>>> security.ns.capability@uid=1000, then?
>> Imo, '.ns' is redundant and 'encoded' in the '@'.
> So how about
> 	security.@uid=1000@@capability ?
Ouch.
> Maybe it's not worth it.

So the .ns is there to be able to possibly extend it in another 
dimension in the future, like have '.foo' there at some point?


>

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

#1673947

On 6/23/2017 4:09 PM, Stefan Berger wrote:
> On 06/23/2017 02:35 PM, Serge E. Hallyn wrote:
>> Quoting Stefan Berger (stefanb@linux.vnet.ibm.com):
>>> On 06/23/2017 12:16 PM, Casey Schaufler wrote:
>>>> On 6/23/2017 9:00 AM, Serge E. Hallyn wrote:
>>>>> Quoting Amir Goldstein (amir73il@gmail.com):
>>>>>> On Thu, Jun 22, 2017 at 9:59 PM, Stefan Berger
>>>>>> <stefanb@linux.vnet.ibm.com> wrote:
>>>>>>> This series of patches primary goal is to enable file capabilities
>>>>>>> in user namespaces without affecting the file capabilities that are
>>>>>>> effective on the host. This is to prevent that any unprivileged user
>>>>>>> on the host maps his own uid to root in a private namespace, writes
>>>>>>> the xattr, and executes the file with privilege on the host.
>>>>>>>
>>>>>>> We achieve this goal by writing extended attributes with a different
>>>>>>> name when a user namespace is used. If for example the root user
>>>>>>> in a user namespace writes the security.capability xattr, the name
>>>>>>> of the xattr that is actually written is encoded as
>>>>>>> security.capability@uid=1000 for root mapped to uid 1000 on the host.
>>>>>>> When listing the xattrs on the host, the existing security.capability
>>>>>>> as well as the security.capability@uid=1000 will be shown. Inside the
>>>>>>> namespace only 'security.capability', with the value of
>>>>>>> security.capability@uid=1000, is visible.
>>>>>>>
>>>>>> Am I the only one who thinks that suffix is perhaps not the best grammar
>>>>>> to use for this namespace?
>>>>> You're the only one to have mentioned it so far.
>>>>>
>>>>>> xattrs are clearly namespaced by prefix, so it seems right to me to keep
>>>>>> it that way - define a new special xattr namespace "ns" and only if that
>>>>>> prefix exists, the @uid suffix will be parsed.
>>>>>> This could be either  ns.security.capability@uid=1000 or
>>>>>> ns@uid=1000.security.capability. The latter seems more correct to me,
>>>>>> because then we will be able to namespace any xattr without having to
>>>>>> protect from "unprivileged xattr injection", i.e.:
>>>>>> setfattr -n "user.whatever.foo@uid=0"
>>>>> I like it for simplifying the parser code.  One concern I have is that,
>>>>> since ns.* is currently not gated, one could write ns.* on an older
>>>>> kernel and then exploit it on a newer one.
>>>> security.ns.capability@uid=1000, then?
>>> Imo, '.ns' is redundant and 'encoded' in the '@'.
>> So how about
>>     security.@uid=1000@@capability ?
> Ouch.
>> Maybe it's not worth it.
>
> So the .ns is there to be able to possibly extend it in another dimension in the future, like have '.foo' there at some point?

Traditionally we have <kind-of-attribute>.<name-of-attribute>
If you want to preserve the kind and name you have to introduce
a third component if you want to have it treated differently
under curtain (e.g. namespaced) conditions. You want to maintain
the kind, because that's already treated specially. You want to
maintain the name because that's what the feature code keys on.
The kind is expected to be first, and the name last, so your new
data needs to be in the middle. You need to identify what you
expect the new bit to be used for because if you're clever enough
to create a reason to add to the attribute name, someone else is,
too. Thus

	security.ns@uid=1000@@.capability
	security.endian@end=big@@.capability

It's better to add fields than to change how a field is
formatted and interpreted.

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

#1676392

On Fri, Jun 23, 2017 at 10:01:46AM +0300, Amir Goldstein wrote:
> On Thu, Jun 22, 2017 at 9:59 PM, Stefan Berger
> <stefanb@linux.vnet.ibm.com> wrote:
> > This series of patches primary goal is to enable file capabilities
> > in user namespaces without affecting the file capabilities that are
> > effective on the host. This is to prevent that any unprivileged user
> > on the host maps his own uid to root in a private namespace, writes
> > the xattr, and executes the file with privilege on the host.
> >
> > We achieve this goal by writing extended attributes with a different
> > name when a user namespace is used. If for example the root user
> > in a user namespace writes the security.capability xattr, the name
> > of the xattr that is actually written is encoded as
> > security.capability@uid=1000 for root mapped to uid 1000 on the host.
> > When listing the xattrs on the host, the existing security.capability
> > as well as the security.capability@uid=1000 will be shown. Inside the
> > namespace only 'security.capability', with the value of
> > security.capability@uid=1000, is visible.
> >
> 
> Am I the only one who thinks that suffix is perhaps not the best grammar
> to use for this namespace?
> xattrs are clearly namespaced by prefix, so it seems right to me to keep
> it that way - define a new special xattr namespace "ns" and only if that
> prefix exists, the @uid suffix will be parsed.
> This could be either  ns.security.capability@uid=1000 or
> ns@uid=1000.security.capability. The latter seems more correct to me,
> because then we will be able to namespace any xattr without having to
> protect from "unprivileged xattr injection", i.e.:
> setfattr -n "user.whatever.foo@uid=0"
> 
> Amir.

Hi Amir,

I was liking the prefix at first, but I'm actually not sure it's worth
it.  THe main advantage would be so that checking for namespace or other
tags could be done always at the same offset simplifying the parser.
But since we will want to only handle namespacing for some tags, and
potentially differently for each task, it won't actually be simpler, I
don't think.

On the other hand we do want to make sure that the syntax we use is
generally usable, so I think simply specifying that >1 tags can each
be separate by '@' should suffice.  So for now we'd only have

	security.capability@uid=100000

soon we'd hopefully have

	security.ima@uid=100000

and eventually trusted.blarb@foo=bar

-serge

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

#1676416

On Wed, Jun 28, 2017 at 8:41 AM, Serge E. Hallyn <serge@hallyn.com> wrote:
> On Fri, Jun 23, 2017 at 10:01:46AM +0300, Amir Goldstein wrote:
>> On Thu, Jun 22, 2017 at 9:59 PM, Stefan Berger
>> <stefanb@linux.vnet.ibm.com> wrote:
>> > This series of patches primary goal is to enable file capabilities
>> > in user namespaces without affecting the file capabilities that are
>> > effective on the host. This is to prevent that any unprivileged user
>> > on the host maps his own uid to root in a private namespace, writes
>> > the xattr, and executes the file with privilege on the host.
>> >
>> > We achieve this goal by writing extended attributes with a different
>> > name when a user namespace is used. If for example the root user
>> > in a user namespace writes the security.capability xattr, the name
>> > of the xattr that is actually written is encoded as
>> > security.capability@uid=1000 for root mapped to uid 1000 on the host.
>> > When listing the xattrs on the host, the existing security.capability
>> > as well as the security.capability@uid=1000 will be shown. Inside the
>> > namespace only 'security.capability', with the value of
>> > security.capability@uid=1000, is visible.
>> >
>>
>> Am I the only one who thinks that suffix is perhaps not the best grammar
>> to use for this namespace?
>> xattrs are clearly namespaced by prefix, so it seems right to me to keep
>> it that way - define a new special xattr namespace "ns" and only if that
>> prefix exists, the @uid suffix will be parsed.
>> This could be either  ns.security.capability@uid=1000 or
>> ns@uid=1000.security.capability. The latter seems more correct to me,
>> because then we will be able to namespace any xattr without having to
>> protect from "unprivileged xattr injection", i.e.:
>> setfattr -n "user.whatever.foo@uid=0"
>>
>> Amir.
>
> Hi Amir,
>
> I was liking the prefix at first, but I'm actually not sure it's worth
> it.  THe main advantage would be so that checking for namespace or other
> tags could be done always at the same offset simplifying the parser.
> But since we will want to only handle namespacing for some tags, and
> potentially differently for each task, it won't actually be simpler, I
> don't think.
>
> On the other hand we do want to make sure that the syntax we use is
> generally usable, so I think simply specifying that >1 tags can each
> be separate by '@' should suffice.  So for now we'd only have

Serge,

I am not sure I am parsing what you are saying correctly (pun intended).
Can you give some examples of xattr names with several @.

>
>         security.capability@uid=100000
>
> soon we'd hopefully have
>
>         security.ima@uid=100000
>

IIUC, the xattr names above should be parsed as:

        security.(([ima|capability])@(uid=100000)

> and eventually trusted.blarb@foo=bar
>

But the trusted xattr name should be parsed as:

        (trusted.blarb)@(uid=100000)

Otherwise it won't be able to pass the xattr_is_trusted() test
which looks only at the trusted prefix.

So we can write it like this, if it makes sense for the parser:
        trusted@uid=100000.blarb

But I don't think that trusted.foo should have a different
userns behavior than trusted.bar down the road.

Admittedly, I am not so much of a security developer myself,
so I prefer to let Casey be the spokesman for the '.ns' prefix.
Casey's proposal seems right to me:

        security.ns@uid=1000@@.capability

We can also stick to a more conventional syntax of a perfect
new namespace 'security.ns', which encapsulates the unprivileged
xattr name completely. This should suffice perfectly for the current
capability V3 needs and is flexible enough to be extended later:

        security.ns.user.1000.security.capability
OR:
        security.ns@uid=1000@@.security.capability

And going forward, just as easy:

        security.ns.user.1000.[trusted|system|user].foo

Amir.

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

#1676694

On 06/28/2017 03:18 AM, Amir Goldstein wrote:
> On Wed, Jun 28, 2017 at 8:41 AM, Serge E. Hallyn <serge@hallyn.com> wrote:
>> On Fri, Jun 23, 2017 at 10:01:46AM +0300, Amir Goldstein wrote:
>>> On Thu, Jun 22, 2017 at 9:59 PM, Stefan Berger
>>> <stefanb@linux.vnet.ibm.com> wrote:
>>>> This series of patches primary goal is to enable file capabilities
>>>> in user namespaces without affecting the file capabilities that are
>>>> effective on the host. This is to prevent that any unprivileged user
>>>> on the host maps his own uid to root in a private namespace, writes
>>>> the xattr, and executes the file with privilege on the host.
>>>>
>>>> We achieve this goal by writing extended attributes with a different
>>>> name when a user namespace is used. If for example the root user
>>>> in a user namespace writes the security.capability xattr, the name
>>>> of the xattr that is actually written is encoded as
>>>> security.capability@uid=1000 for root mapped to uid 1000 on the host.
>>>> When listing the xattrs on the host, the existing security.capability
>>>> as well as the security.capability@uid=1000 will be shown. Inside the
>>>> namespace only 'security.capability', with the value of
>>>> security.capability@uid=1000, is visible.
>>>>
>>> Am I the only one who thinks that suffix is perhaps not the best grammar
>>> to use for this namespace?
>>> xattrs are clearly namespaced by prefix, so it seems right to me to keep
>>> it that way - define a new special xattr namespace "ns" and only if that
>>> prefix exists, the @uid suffix will be parsed.
>>> This could be either  ns.security.capability@uid=1000 or
>>> ns@uid=1000.security.capability. The latter seems more correct to me,
>>> because then we will be able to namespace any xattr without having to
>>> protect from "unprivileged xattr injection", i.e.:
>>> setfattr -n "user.whatever.foo@uid=0"
>>>
>>> Amir.
>> Hi Amir,
>>
>> I was liking the prefix at first, but I'm actually not sure it's worth
>> it.  THe main advantage would be so that checking for namespace or other
>> tags could be done always at the same offset simplifying the parser.
>> But since we will want to only handle namespacing for some tags, and
>> potentially differently for each task, it won't actually be simpler, I
>> don't think.
>>
>> On the other hand we do want to make sure that the syntax we use is
>> generally usable, so I think simply specifying that >1 tags can each
>> be separate by '@' should suffice.  So for now we'd only have
> Serge,
>
> I am not sure I am parsing what you are saying correctly (pun intended).
> Can you give some examples of xattr names with several @.
>
>>          security.capability@uid=100000
>>
>> soon we'd hopefully have
>>
>>          security.ima@uid=100000
>>
> IIUC, the xattr names above should be parsed as:
>
>          security.(([ima|capability])@(uid=100000)
>
>> and eventually trusted.blarb@foo=bar
>>
> But the trusted xattr name should be parsed as:
>
>          (trusted.blarb)@(uid=100000)
>
> Otherwise it won't be able to pass the xattr_is_trusted() test
> which looks only at the trusted prefix.

To be precise, it looks at 'trusted.', including the dot.

>
> So we can write it like this, if it makes sense for the parser:
>          trusted@uid=100000.blarb

For the parser I think it would be easier to parse what Serge is 
proposing, and it would pass the existing xattr_is_trusted() call.



>
> But I don't think that trusted.foo should have a different
> userns behavior than trusted.bar down the road.
>
> Admittedly, I am not so much of a security developer myself,
> so I prefer to let Casey be the spokesman for the '.ns' prefix.
> Casey's proposal seems right to me:
>
>          security.ns@uid=1000@@.capability
>
> We can also stick to a more conventional syntax of a perfect
> new namespace 'security.ns', which encapsulates the unprivileged
> xattr name completely. This should suffice perfectly for the current
> capability V3 needs and is flexible enough to be extended later:
>
>          security.ns.user.1000.security.capability
> OR:
>          security.ns@uid=1000@@.security.capability
>
> And going forward, just as easy:
>
>          security.ns.user.1000.[trusted|system|user].foo
>
> Amir.
>

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

#1676718

Quoting Amir Goldstein (amir73il@gmail.com):
> On Wed, Jun 28, 2017 at 8:41 AM, Serge E. Hallyn <serge@hallyn.com> wrote:
> > Hi Amir,
> >
> > I was liking the prefix at first, but I'm actually not sure it's worth
> > it.  THe main advantage would be so that checking for namespace or other
> > tags could be done always at the same offset simplifying the parser.
> > But since we will want to only handle namespacing for some tags, and
> > potentially differently for each task, it won't actually be simpler, I
> > don't think.
> >
> > On the other hand we do want to make sure that the syntax we use is
> > generally usable, so I think simply specifying that >1 tags can each
> > be separate by '@' should suffice.  So for now we'd only have
> 
> Serge,
> 
> I am not sure I am parsing what you are saying correctly (pun intended).
> Can you give some examples of xattr names with several @.
> 
> >
> >         security.capability@uid=100000
> >
> > soon we'd hopefully have
> >
> >         security.ima@uid=100000
> >
> 
> IIUC, the xattr names above should be parsed as:
> 
>         security.(([ima|capability])@(uid=100000)

not sure what you mean by the parentheses.  Point in these two
examples being that only uid= would be accepted as 'tags', and
only ima and capability would support the tag.  As we'd discussed
we might support uid= (with no number) as indicating any namespace
not mapping kuid 0 would work.

> > and eventually trusted.blarb@foo=bar
> >
> 
> But the trusted xattr name should be parsed as:
> 
>         (trusted.blarb)@(uid=100000)

Sorry, my point there wasn't trusted, I had meant to put in more
tags, which was the point:

	security.capability@uid=100000@smack=container_x

We don't yet know what smack= would mean, but we do know that at
some point there may be > 1 tags.

Importantly, in order to not limit our future behavior, for now
we would refuse writing >1 tags.  (That way we don't risk the problem,
in the future, that someone can boot an older kernel andw rite a xattr
without all the privileges which the new kernel requires.)

> Otherwise it won't be able to pass the xattr_is_trusted() test
> which looks only at the trusted prefix.
> 
> So we can write it like this, if it makes sense for the parser:
>         trusted@uid=100000.blarb

That's actually specifically what I'm arguing against.  I'm arguing
that the full xattr should come first, as we should not bother
checking for tags until we've verified that the xattr supports them.

> But I don't think that trusted.foo should have a different
> userns behavior than trusted.bar down the road.

Perhaps not for trusted, but perhaps it will.  And for security.*
it definately does.  Selinux does not support namespace tags.
Smack one day may, but perhaps with different behavior than ima.

> Admittedly, I am not so much of a security developer myself,
> so I prefer to let Casey be the spokesman for the '.ns' prefix.
> Casey's proposal seems right to me:
> 
>         security.ns@uid=1000@@.capability

Right I was going to reply to his email, but yours seemed to come
earlier so I picked it :)  I wasn't trying to pick on you :)

> We can also stick to a more conventional syntax of a perfect
> new namespace 'security.ns', which encapsulates the unprivileged

If we were going this route I definately would have preferred
security.ns@uid=1000@@.capability.

I've cc:d linux-api at this point as it seems the right thing to
do :)

thanks,
-serge

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

#1673817

On Thu, Jun 22, 2017 at 02:59:46PM -0400, Stefan Berger wrote:
> This series of patches primary goal is to enable file capabilities
> in user namespaces without affecting the file capabilities that are
> effective on the host. This is to prevent that any unprivileged user
> on the host maps his own uid to root in a private namespace, writes
> the xattr, and executes the file with privilege on the host.
> 
> We achieve this goal by writing extended attributes with a different
> name when a user namespace is used. If for example the root user
> in a user namespace writes the security.capability xattr, the name
> of the xattr that is actually written is encoded as
> security.capability@uid=1000 for root mapped to uid 1000 on the host.
> When listing the xattrs on the host, the existing security.capability
> as well as the security.capability@uid=1000 will be shown. Inside the
> namespace only 'security.capability', with the value of
> security.capability@uid=1000, is visible.

Hi Stefan,

Got a question. If child usernamespace sets a
security.capability@uid=1000, can any of the parent namespace remove it?

IOW, I set capability from usernamespace and tried to remove it from
host and that failed. Is that expected.

# Inside usernamespce
$setcap cat_net_raw+ep foo.txt

# outside user namespace
$listxattr foo.txt
 xattr: security.capability@uid=1000
 xattr: security.selinux

# outside user namespace
setfattr -x security.capability@uid foo.txt
setfattr: foo.txt: Invalid argument

Doing a strace shows removexattr() failed. May this will need fixing?

removexattr("testfile.txt", "security.capability@uid") = -1 EINVAL
(Invalid argument)

Vivek

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

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | linux.kernel

csiph-web