On 6/23/2017 11:35 AM, Serge E. Hallyn wrote: > Quoting Stefan Berger (stefanb@xxxxxxxxxxxxxxxxxx): >> 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@xxxxxxxxx): >>>>> On Thu, Jun 22, 2017 at 9:59 PM, Stefan Berger >>>>> <stefanb@xxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html > _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/containers
