Re: [libvirt] [RFC PATCH 2/2] LXC: Create ro overlay mounts only if we're not within a user namespace

On 06/26/2013 05:38 PM, Daniel P. Berrange wrote: > On Wed, Jun 26, 2013 at 10:26:10AM +0800, Gao feng wrote: >> On 06/26/2013 04:39 AM, Daniel P. Berrange wrote: >>> On Thu, Jun 13, 2013 at 08:02:18PM +0200, Richard Weinberger wrote: >>>> Within a user namespace root can remount these filesysems at any >>>> time rw. >>>> Create these mappings only if we're not playing with user namespaces. >>> >>> This is a problem with the way we're initializing mounts in the >>> user namespace. >> >> This problem exists even libvirt lxc doesn't support user namespace. > > Yes, and this is a problem that user namespace is intended to > solve. > >>> We need to ensure that the initial mounts setup >>> by libvirt can't be changed by admin inside the container. Preventing >>> the container admin from remounting or unmounting these mounts is key >>> to security. >>> >>> IIUC, the only way to ensure this is to start a new user namespace >>> /after/ setting up all mounts. >>> >> >> start a new user namespace means the container will lose controller of >> mount namespace. so the container can't do mount operation too, though >> we only can mount a little of filesystems in un-init user namespace. > > Merely being able to unmount is sufficient to exploit the host. Consider > that the container was configured with the following mapping > > / -> / > /export/mycontainer/home -> /home > > Now, if the container admin can umount /home, then they can now > see the home directory contents of the host. At least this is > likely to be information leakage, and if any of the host home > directories have UIDs that overlap with those assigned to the > container ID map, you have a potentially exploitable situation. > > Hence we need to ensure that the container cannot unmount or > remount anything setup by libvirt. AFAICT, this means that all > the mounts libvirt does, must be performed in a seprate user > namespace to that wit hthe container will eventually run in. > Libvirt mounts something for the container in one user namesapce, and then libvirt calls unshare to create a new user namespace and start the init task of container. Yes, the users in container can't do mount/unmount/remount on all of filesystem. but they can call unshare to create a new mount namespace, and they will have rights to mount/unmount/remount in this new created mount namespace. they can still umount /home to see the home directory contents of host.