On Sat, 2018-06-16 at 03:04 +1000, Aleksa Sarai wrote: > On 2018-06-15, James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx > > 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
Attachment:
signature.asc
Description: This is a digitally signed message part
