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

[Gao feng]

On 06/26/2013 07:01 PM, Daniel P. Berrange wrote:
> 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.
> 

Please also setup the uid_map/gid_map for the unshared user namespace.
even in container, user has rights to setup these two files.

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

in terminal one
$ id
uid=1000(gaofeng) gid=1000(gaofeng) groups=1000(gaofeng)
$ ./unshare --mount --user /bin/sh
sh-4.2$ echo $$
17110
sh-4.2$

in other terminal,setup id map for new userns.
$echo 0 1000 1 > /proc/17110/uid_map
$echo 0 1000 1 > /proc/17110/gid_map

and then in terminal one
sh-4.2$ umount -l /home/