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? 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@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html > _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/containers
