[lxc-devel] [PATCH V1] Use pivot_root and umount2 instead of chroot

[Serge Hallyn]

Quoting Michael H. Warfield (mhw at WittsEnd.com):
> On Mon, 2014-09-01 at 03:24 +0000, Steven Stewart-Gallus wrote:
> > chrooting leaves the old mount information in /proc/mounts and gives
> > me anxiety. Explicitly switch root directories and unmount the old
> > root directory.
> 
> > Signed-off-by: Steven Stewart-Gallus <sstewartgallus00 at mylangara.bc.ca>
> 
> (/me checks watch and checks calendar)...  Here there be dragons.
> 
> We have gone back and forth on this for years.  There were SERIOUS
> reasons for the decisions that were made (maybe right, maybe wrong and
> which maybe changed now).  Not just the pollution of the mount table
> (which is a seriouos PITA) but the issues of security and mount (mount
> remount) security in containers and the interaction with other
> containers.  This subject cause no ends of problems of ro/rw remount
> issues across templates.
> 
> Has this been tested against the security and operational cases we have
> faced and evaluated in the past?  I'd like to hear from Stephane and
> Serge on this but I'm extremely leary of this lacking a security
> evaluation of this change.  This is at the heart of a security issue for
> the whole project.
> 
> IF things have changed and IF this can be done securely and IF this can
> be done where one container does NOT contaminate the state of another, I
> am comfortable with it.  With out that assurance, I am not.
> 
> This needs some serious evaluation, IMNSO.

I don't think we've given much thought to this particular code path,
that was mainly at container starts.  This chroot is done only to
complete a mknod.  But the same concerns apply.  (1) On say a fedora
system, where / is MS_SHARED, doing the umount2 after pivot_root could
result in umount being forwarded and wreaking havoc on the host.
(2) on a system with a ramfs rootfs (or certain other constraints)
the pivot_root will just return -EINVAL as kernel will refuse.

Since we exit immediately after the mkdir and mknod, I don't think
polluted mount tables should be an issue, so I don't think it's worth
the complication unles there are other concerns.

thanks,
-serge