3 ms·
> I think it's subtler than that. It is mostly safe to run a contained process as "root" because in theory the ways that root access can be exercised is highly
by cyphar 8y ago
> I think it's subtler than that. It is mostly safe to run a contained process as "root" because in theory the ways that root access can be exercised is highly sandbox by the use of various namespaces, as well as things like capability restrictions (you generally don't have CAP_SYS_ADMIN or a few others), limited syscall attack surface (you generally have a syscall allowlist via seccomp-bpf), etc.
I disagree. It is definitely "safer" than running as root on the host -- but that shouldn't be the baseline. Honestly, I would argue that not using user namespaces (or non-root inside the container) is basically negligence at this point. Yes, it's annoying to do it with Docker, but other runtimes have solved this problem.
LXC actually explicitly states that privileged (non-userns) containers are fundamentally unsafe and I agree. When you look at the wide array of ns_capable and other userns checks that protect against all sorts of attacks, you really start to not trust anything that doesn't use user namespaces. Kernel developers assume that container runtimes are using user namespaces if they are trying to secure something.
Additionally, yes capabilities help. But you still have traditional Unix DAC issues (which is what is leveraged here).
> and this vulnerability is notable precisely because it's one of the rare ways to exercise that root privilege outside the container.
I would argue there's several very foundational security problems (which I'm trying to fix) that are made significantly worse by running a container process as root. Please don't do it.
- geofft 8y agoCan you use user namespaces with a released version of Docker or Kubernetes? I think the answer is no? (Or can you do it with Kubernetes + some other container runtime?) We run Kubernetes + Docker with a policy of no root inside containers (we map you to your normal UID inside the container), but most of the rabbit hole we got into was trying to figure out the implications of setuid binaries inside the container. It seems like on a normal system, setuid binaries inside a container do in fact get host root unless you tell Docker to drop those capabilites, and also fscaps aren't really usable in a container image, I think.
- cyphar 8y agoUser namespaces have been supported in Docker since 1.10. I don't think that it's necessarily "supported" in Kubernetes -- there was a KEP to add support last year but it's still a while away. As for setuid and fscaps, they both work in containers (container images can contain them but some filesystems don't support xattrs such as AUFS). And yes, without user namespaces, they escalate to host root. You can use no_new_privs which blocks things like setuid or fscap but it also can cause problems (though I think you can enable no_new_privs in Kubernetes).
- ofrzeta 8y agoOpenShift (Kubernetes distro) is running all pods with random UIDs, and running a pod/container as root requires special privileges that only a cluster admin can grant. Also OpenShift is not vulnerable to this attack due the use of SELinux which is mandatory for OpenShift installations.