[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 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.

I didn't do test now, but I think this problem is existing.
User namespace can't do this job well.

>> So maybe we should fix this problem by selinux.
> 
> User namespaces are intended to allow for secure containers without
> the need to run SELinux.
> 
> Daniel
>