From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from bedivere.hansenpartnership.com ([66.63.167.143]:46526 "EHLO bedivere.hansenpartnership.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934312AbeFORWR (ORCPT ); Fri, 15 Jun 2018 13:22:17 -0400 Message-ID: <1529083329.4048.19.camel@HansenPartnership.com> Subject: Re: shiftfs status and future development From: James Bottomley To: Aleksa Sarai Cc: containers@lists.linux-foundation.org, Matthew Wilcox , Seth Forshee , Christian Brauner , Tyler Hicks , linux-fsdevel@vger.kernel.org Date: Fri, 15 Jun 2018 10:22:09 -0700 In-Reply-To: <20180615170435.pt2qtnr762z7w634@gordon> References: <20180614184448.GC30028@ubuntu-xps13> <20180615135638.GA29299@mail.hallyn.com> <20180615145917.GF30028@ubuntu-xps13> <20180615152529.GA23527@bombadil.infradead.org> <1529078955.4048.12.camel@HansenPartnership.com> <20180615170435.pt2qtnr762z7w634@gordon> Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="=-31wRXCKADqxkSf5wv5qz" Mime-Version: 1.0 Sender: linux-fsdevel-owner@vger.kernel.org List-ID: --=-31wRXCKADqxkSf5wv5qz Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, 2018-06-16 at 03:04 +1000, Aleksa Sarai wrote: > On 2018-06-15, James Bottomley > wrote: > > > > =C2=A0- Supports any id maps possible for a user namespace > > >=20 > > > 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.=C2=A0=C2=A0Then shiftfs reads the xattr and presents the files wi= th the > > > container's idea of what the UID is? > >=20 > > I've got an experimental patch set that does the *mark* as an > > xattr.=C2=A0 >=20 > 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 Then in the location we can block the potential exploits. When the tenant is building an unprivileged container, it can do mount -t shiftfs And the 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 so that regular tenant access can be secured (or even prohibited) but the tenant can still do mount -t shiftfs 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 --=-31wRXCKADqxkSf5wv5qz Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- iHUEABMIAB0WIQTnYEDbdso9F2cI+arnQslM7pishQUCWyP1wgAKCRDnQslM7pis hbjcAP9Q5DUHXMykOOX+BA8oHS2/eYehzc5MEXLDXpRYEaJgcwEAnLWWiw9bq5bO EKVhxSk1YhFXmINRwJo0CcKV/L/TOsg= =c3Bc -----END PGP SIGNATURE----- --=-31wRXCKADqxkSf5wv5qz--