Re: [PATCH 0/3] Enable namespaced file capabilities
From: James Bottomley
Date: Thu Jun 22 2017 - 20:13:50 EST
On Thu, 2017-06-22 at 18:36 -0500, Serge E. Hallyn wrote:
> Quoting James Bottomley (James.Bottomley@xxxxxxxxxxxxxxxxxxxxx):
> > On Thu, 2017-06-22 at 14:59 -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.
> > I'm a bit bothered by the @uid=1000 suffix. What if I want to use
> > this capability but am dynamically mapping the namespaces (i.e. I
> > know I want unprivileged root, but I'm going to dynamically select
> > the range to map based on what's currently available on the
> > orchestration system). If we stick with the @uid=X suffix, then
> > dynamic mapping won't work because X is potentially different each
> > time and there'll be a name mismatch in my xattrs. Why not just
> > make the suffix @uid, which means if root is mapped to any
> > unprivileged uid then we pick this up otherwise we go with the
> > unsuffixed property?
> > As far as I can see there's no real advantage to discriminating
> > userns specific xattrs based on where root is mapped to, unless
> > there's a use case I'm missing?
> Yes, the use case is: to allow root in the container to set the
> privilege itself, without endangering any resources not owned by
> that root.
OK, so you envisage the same filesystem being mounted in different user
namespaces and being able to see their own value for the xattr. It
still seems a bit weird that they'd be able to change file contents and
have that seen by the other userns but not xattrs.
> If you're going to have a root owned host-wide
> orchestration system setting up the rootfs, then you don't
> necessary need this at all.
I wasn't thinking it would be root owned, just that it would have a
predefined range of allowed uids and be able to map multiple containers
to subsets of these.
> As you say a @uid to say "any unprivileged userns" might be useful.
> The implication is that root on the host doesn't trust the image
> enough to write a real global file capability, but trusts it enough
> to 'endanger' all containers on the host. If that's the case, I have
> no objection to adding this as a feature.
Yes, precisely. The filesystem is certified as permitted to override
the xattr whatever unprivileged mapping for root is in place.
How would we effect the switch? I suppose some global flag because I
can't see we'd be mixing use cases in a physical system.