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 :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list