[Lxc-users] dropping capabilities

[Trent W. Buck]

Daniel Lezcano <daniel.lezcano at free.fr> writes:

> I am not sure there is a default set of capabilities to be dropped.
> Certainly some should be dropped like CAP_SYS_MODULE but others will
> depend on what the user expect to do with the container and what scripts
> will be run inside the container.

I was thinking about CAP_SYS_MODULE... it would be useful if
iptables-restore(8) in a container could load modules like
xt_recent.ko...  but will it try to load xt_recent.ko from the dom0's
filesystem, or the container's?

If a malicious root user in a container is allowed to modprobe arbitrary
kernel modules, what would likely exploits be?  The only one I can think
of offhand is "modprobe kvm" hard-hanging the dom0 on a machine that's
already running OpenVZ and VMware Server 1.x.

Plan B for per-continer firewalls is simply that the domU admin has to
to call the dom0 admin and ask him to add xt_foo to dom0:/etc/modules.

> We have certainly think about the root user inside a container, is it
> secure ? IMO, until the user namespace is not complete, it is not secure.

Is there a roadmap for that (or for "secure" containers in general)?

>> CAP_SYS_TIME
>>    should be dropped
>>
> yes and ensure /dev/rtc is read-only and protected with the cgroup
> devices whitelist.

In 0.7.2's lxc-ubuntu template, it has

    lxc.cgroup.devices.deny = a
    ...
    lxc.cgroup.devices.allow = c 254:0 rwm

I guess that should be change to this?

    lxc.cgroup.devices.deny = a
    ...
    lxc.cgroup.devices.allow = c 254:0 rm

>> CAP_SYS_TTY_CONFIG
>>    should be dropped
>>
> I am not sure, won't getty need it ?

FWIW, my gettys don't (Ubuntu 10.04 dom0 and domU, LXC 0.7.2).