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

[Daniel P. Berrange]

On Wed, Jun 26, 2013 at 05:56:19PM +0800, Gao feng wrote:
> 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.

An existing filesystem mount can only be remounted/unmounted by the
(user ID, usernamespace) that originally mounted it. So even if you
start a new mount namespace, you cannot unmount stuff setup by the
parent user namespace.

# unshare --mount --user /bin/sh
sh-4.2$ umount /sys/kernel/debug
umount: /sys/kernel/debug: Invalid argument

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|