Um. I see at least one security issue already.
Even if this is inside a VM, it might give the wrong message to someone wanting to try this for themselves.
Then a compromise would need to be:
Local VM user -> root VM user -> local LiveCD user -> root liveCD user -> hardware exploits
Or as solomon hykes, the docker creator himself said recently:
"""When we feel comfortable saying that Docker out-of-the-box can safely contain untrusted uid0 programs, we will say so clearly."""
http://opensource.com/business/14/7/docker-security-selinux seems to have some information. But to refuse the points there, on my system:
a) docker containers do not have a /dev/mem
b) /sys/fs is mounted read-only
c) /dev/sd* is not visible
And so on. What's the thing with cgroups? Can a container delete the host's cgroups? Can it overwrite it's own cgroup constraints?
Can you or someone tell me if there is something I can try out on my own to understand actual issues? I run my containers unprivileged (which is the default) if it matters.
Again, all I am asking is for some material to educate myself on what actually the flaws are. All I have seen are vague articles claiming it's insecure.
But nothing is stopping you from creating a binary and running it as root that perhaps mounts those filesystems, or sends ioctls / badness to the kernel.
I'm just shooting from the hip here and might be wrong, but I'm almost certain devices aren't namespaced. If you were to mknod a block device with the right major / minor numbers as the host's sda/sdb/etc, what would stop you from mounting the host's root filesystem and making changes?
Granted the "work around" is to drop the privileges of the containers as much as possible, use sVirt (via SELinux), drop as many capabilities as possible, don't run untrusted containers, etc. But this isn't a theoretical security problem, it is a real big attack surface.
Thanks for the info.