shiftfs status and future development

[James Bottomley]

On Sat, 2018-06-16 at 03:04 +1000, Aleksa Sarai wrote:
> On 2018-06-15, James Bottomley <James.Bottomley at HansenPartnership.com
> > wrote:
> > > >  - Supports any id maps possible for a user namespace
> > > 
> > > Have we already ruled out storing the container's UID/GID/perms
> > > in an extended attribute, and having all the files owned by the
> > > owner of the container from the perspective of the unshifted
> > > fs.  Then shiftfs reads the xattr and presents the files with the
> > > container's idea of what the UID is?
> > 
> > I've got an experimental patch set that does the *mark* as an
> > xattr. 
> 
> I forgot to ask you about this when we all met face-to-face -- can
> you go over what the purpose of marking the mounts before being able
> to shifts is? When I saw your demo at LPC I was quite confused about
> what it was doing (I think you mentioned it was a security feature,
> but I must admit I didn't follow the explanation).

OK, so the basic security problem is that an unprivileged tenant cannot
be allowed arbitrary access to both the shifted and underlying
unshifted locations because they can do writes to the shifted mount
that appear at real uid/gid 0 in the underlying unshifted location,
setting up all sorts of unpleasant threats of which suid execution is
just the most obvious one.

My mount marking solution, which the v2 (and forthcoming v3) has is the
idea that the admin buries the real underlying location deep in a path
inaccessible (to the tenant) part of the filesystem and then exposes a
marked mount point to the tenant by doing

mount -t shiftfs -o mark <underlying location> <tenant visible>

Then in the <tenant visible> location we can block the potential
exploits.  When the tenant is building an unprivileged container, it
can do

mount -t shiftfs <tenant visible> <container location>

And the <container location> will now have the shifting in place.

This scheme is ephemeral (the marked mount has to be recreated on every
boot) and rather complex, so the alternative is to add a permanent mark
to <underlying location> so that regular tenant access can be secured
(or even prohibited) but the tenant can still do

mount -t shiftfs <underlying location> <container location>

To get the shifting properties in the container.  In this version of
the scheme, the shift mountable directory is marked with a security
xattr that is permanent (survives reboot) but requires that the
filesystem support xattrs, of course.

The down side of the xattr scheme is that the securing against the
tenant part becomes an xattr enforced thing rather than a shiftfs
enforced thing, so it has to be an additional patch to the kernel
itself rather than being inside a self contained module.

James
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: This is a digitally signed message part
URL: <http://lists.linuxfoundation.org/pipermail/containers/attachments/20180615/a3102560/attachment.sig>