4 ms·

> However, it is blocked through correct use of user namespaces (where the host root is not mapped into the container's user namespace). In other words, this w

by wicket 8y ago

> However, it is blocked through correct use of user namespaces (where the host root is not mapped into the container's user namespace). In other words, this won't affect anyone who understands the implications of running a process as root. Unfortunately, the sad truth is that most people I've come across who have "lots of experience" with implementing Docker containers, do not even understand the basics of how they work, let alone the implications of root access. I've interviewed candidates who claim to know Docker but can't even tell me how Docker differs from traditional virtualisation or how it achieves its isolation. The best explanation that most of them come up with is, "Docker containers are more lightweight". This sort of vulnerability should have been a non-issue but it has gained attention due to the sheer amount of incorrectly configured containers in the wild. This was an accident waiting to happen, and I doubt we've heard the last of this sort of thing.

tyingq 8y ago
Docker runs privileged by default, doesn't it? Seems unfair to put all the blame on the end users of it.
cpuguy83 8y ago
The thing is, you would have to disallow running as root in the system itself, including suid binaries and other things (e.g. docker exec -u root). User namespaces forces this. It's not just about not running as root, it's making sure the container cannot map to the real UID 0.
geofft 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. Yes, it's wrong to not understand that the runc process runs as root. But I think it's only very slightly less wrong to claim that a process inside the container has root access in the way that, say, ssh root@host-system has root access. It mostly does not, and this vulnerability is notable precisely because it's one of the rare ways to exercise that root privilege outside the container. We looked at this at $work and got into a serious rabbit hole about how exactly Linux capabilities work. I think if I started asking interviewees to explain permitted vs. effective capability sets and how file and process capabilities differ, I'd never hire anyone. (And I think to figure out yourself how to "correctly configure" a container, you need to have at least some understanding of that.)
- wicket 8y ago
  > I think it's subtler than that. It is mostly safe to run a 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. Yes, it's wrong to not understand that the runc process runs as root. But I think it's only very slightly less wrong to claim that runc has root access in the way that, say, ssh root@host-system has root access. It mostly does not, and this vulnerability is notable in that it's one of the few ways to exercise that root privilege. > We looked at this at $work and got into a serious rabbit hole about how exactly Linux capabilities work. I think if I started asking interviewees to explain permitted vs. effective capability sets and how file and process capabilities differ, I'd never hire anyone. (And I think to figure out yourself how to "correctly configure" a container, you need to have at least some understanding of that.) I think you've hit the nail on the head. I only ask those interview questions because I believe it's important to find out just how much a candidate understands. I have to admit I've let some of these things go, otherwise I'd never hire anyone either. I think in the end what it comes down to is that Docker is an ambitious project that is somewhat flawed from a security perspective. There have been numerous namespace vulnerabilities to date and I expect there will be plenty more found in the future.
  - nicoburns 8y ago
    I believe there was work on non-root container host processes going on at some point? Did that ever get to a usable state?
    - geofft 8y ago
      Rootless containers using user namespaces was merged into runc in March 2017: https://github.com/opencontainers/runc/pull/774 https://github.com/opencontainers/runc/pull/774 A week ago Docker gained support for running dockerd as non-root: https://github.com/moby/moby/pull/38050 https://github.com/moby/moby/pull/38050 And there is this project for running Kubernetes as non-root: https://github.com/rootless-containers/usernetes https://github.com/rootless-containers/usernetes
SAI_Peregrinus 8y ago
I've done pretty much nothing with Docker (we use it at work to ensure consistent builds, all I do involving is run the shell script that uses it to build the code.) I'd say Docker is a rather spiffed-up version of BSD chroot jails, with a repository and more than just filesystem isolation. Jails for all the things. Probably just as wrong as the "lightweight virtualization" but I found it interesting that people claiming to have experience with Docker would immediately compare it with virtualization instead of jails. Not enough BSD?

by wicket 8y ago

tyingq 8y ago

Docker runs privileged by default, doesn't it? Seems unfair to put all the blame on the end users of it.

cpuguy83 8y ago

The thing is, you would have to disallow running as root in the system itself, including suid binaries and other things (e.g. docker exec -u root). User namespaces forces this. It's not just about not running as root, it's making sure the container cannot map to the real UID 0.

geofft 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. Yes, it's wrong to not understand that the runc process runs as root. But I think it's only very slightly less wrong to claim that a process inside the container has root access in the way that, say, ssh root@host-system has root access. It mostly does not, and this vulnerability is notable precisely because it's one of the rare ways to exercise that root privilege outside the container. We looked at this at $work and got into a serious rabbit hole about how exactly Linux capabilities work. I think if I started asking interviewees to explain permitted vs. effective capability sets and how file and process capabilities differ, I'd never hire anyone. (And I think to figure out yourself how to "correctly configure" a container, you need to have at least some understanding of that.)

wicket 8y ago
> I think it's subtler than that. It is mostly safe to run a 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. Yes, it's wrong to not understand that the runc process runs as root. But I think it's only very slightly less wrong to claim that runc has root access in the way that, say, ssh root@host-system has root access. It mostly does not, and this vulnerability is notable in that it's one of the few ways to exercise that root privilege. > We looked at this at $work and got into a serious rabbit hole about how exactly Linux capabilities work. I think if I started asking interviewees to explain permitted vs. effective capability sets and how file and process capabilities differ, I'd never hire anyone. (And I think to figure out yourself how to "correctly configure" a container, you need to have at least some understanding of that.) I think you've hit the nail on the head. I only ask those interview questions because I believe it's important to find out just how much a candidate understands. I have to admit I've let some of these things go, otherwise I'd never hire anyone either. I think in the end what it comes down to is that Docker is an ambitious project that is somewhat flawed from a security perspective. There have been numerous namespace vulnerabilities to date and I expect there will be plenty more found in the future.
- nicoburns 8y ago
  I believe there was work on non-root container host processes going on at some point? Did that ever get to a usable state?
  - geofft 8y ago
    Rootless containers using user namespaces was merged into runc in March 2017: https://github.com/opencontainers/runc/pull/774 https://github.com/opencontainers/runc/pull/774 A week ago Docker gained support for running dockerd as non-root: https://github.com/moby/moby/pull/38050 https://github.com/moby/moby/pull/38050 And there is this project for running Kubernetes as non-root: https://github.com/rootless-containers/usernetes https://github.com/rootless-containers/usernetes

SAI_Peregrinus 8y ago

I've done pretty much nothing with Docker (we use it at work to ensure consistent builds, all I do involving is run the shell script that uses it to build the code.) I'd say Docker is a rather spiffed-up version of BSD chroot jails, with a repository and more than just filesystem isolation. Jails for all the things. Probably just as wrong as the "lightweight virtualization" but I found it interesting that people claiming to have experience with Docker would immediately compare it with virtualization instead of jails. Not enough BSD?