3 ms·

Whilst from an overall security perspective, this may not be that meaningful (the pre-req's are CAP_SYS_ADMIN or --privileged), it's still a really neat hack.

Whilst from an overall security perspective, this may not be that meaningful (the pre-req's are CAP_SYS_ADMIN or --privileged), it's still a really neat hack. Also a good demonstration of how runc container security is really just Linux security, and the isolation provided by that type of container, is dependent on underlying Linux features. I could see circumstances where this would be of practical use, where you've landed in a privileged container and are looking for a relatively easy/universal breakout to the underlying node. The ToB breakdown is cool too as the initial tweet was a bit hard to parse, unless your Bashfu is good. (ofc the post from ToB I'm really looking forward to hasn't been released yet, which is what they found in the Kubernetes audit)

panpanna 7y ago
Two minor remarks: 1. Docker is not synonymous with Linux containers. LXC for example has always had much better security than Docker despite using the same infrastructure. 2. You don't need to interface the kennel directly. There is for example a Google project (gvisor?) that acts as a syscall proxy in userland to combat these types of problems.
- rtempaccount1 7y ago
  Out of curiosity, what makes you say that LXC has better security than Docker? What aspects of LXCs design or implementation provide additional security controls over those of Docker?
  - panpanna 7y ago
    For example LXC containers are unprivileged by default. If you escape the container you end up as a normal user on host, not root. LXC main dev is on HN. I'm sure he can explain this much better.
    - rtempaccount1 7y ago
      I'm not sure I follow you here. The Docker daemon runs as root (which is kind of inevitable, if you don't then you end up needing hacks like slirp4netns to hook up networking) However, there's nothing innately inside Docker that requires contained processes to run as root. Indeed it's a standard part of recommended Docker security guidance not to run your contained processes as the root user. Docker also provide the facility to enable user namespaces at the daemon level, so that root inside the container != root on the host.
      - zapita 7y ago
        That’s correct. Lxc is not “more secure” than Docker in any meaningful way. They are equivalent in their use of the Linux containment “plumbing”: cgroups, namespaces, capabilities, etc.
        panpanna 7y ago
        The "plumbing" is the same but they set it up slightly differently which in the end affects things like security. For example user mappings were handled very differently in lxc compared to (earlier versions of) docker. https://linuxcontainers.org/lxc/security/ https://linuxcontainers.org/lxc/security/
        cyphar 7y ago
        LXC supports user namespaces where containers are isolated from one another. LXD furthers this by remapping containers on restart (so you can change mappings). And you can "punch out" individual mappings for shared volumes and so on. Docker doesn't support this. In fact the recent expansion of the number of mappings allowed by the kernel is work done by Christian Brauner (an LXC maintainer who I collaborate with) -- this feature is so useful to LXC that they had to add the ability to have more mappings. LXC also supports unprivileged operation (which I named "rootless mode"). Docker gained support for this very recently as an experimental feature in 19.03 (still not released), but LXC has supported it (and defaulted to it whenever possible) for years. Though, the Docker one is arguably better in some respects of lack-of-privilege (thanks to great work from Akihiro Suda and Guissupe Scrvano) but it's still new. LXC also has put a lot more work into fundamental security work (both in-kernel and within LXC). Disclaimer: I maintain runc, the runtime Docker uses. There is no question that LXC has better engineering in this department. I collaborate with them quite often, but they have more engineers working on fundamental problems within containers.
  - throw2016 7y ago
    LXC is daemonless, there is no process hanging around after the container start, so it starts the container and uses any privileges required to setup things like networking, mounts etc and then drops privileges. LXC had unprivileged container support since 2013 so that part is fairly mature now. 'Unprivileged' in this case means the container process itself is running as a normal user.
    - cyphar 7y ago
      LXC does have a container manager though, which is a single process that stays alive for the life of a single container. Within runc (the runtime Docker uses), we don't have a container manager but the downside is that now the upper level needs to keep alive the descriptors and other kernel objects that allow for safe container management by the runtime. [I maintain runc, and collaborate with the LXC folks.]

panpanna 7y ago

Two minor remarks: 1. Docker is not synonymous with Linux containers. LXC for example has always had much better security than Docker despite using the same infrastructure. 2. You don't need to interface the kennel directly. There is for example a Google project (gvisor?) that acts as a syscall proxy in userland to combat these types of problems.

rtempaccount1 7y ago
Out of curiosity, what makes you say that LXC has better security than Docker? What aspects of LXCs design or implementation provide additional security controls over those of Docker?
- panpanna 7y ago
  For example LXC containers are unprivileged by default. If you escape the container you end up as a normal user on host, not root. LXC main dev is on HN. I'm sure he can explain this much better.
  - rtempaccount1 7y ago
    I'm not sure I follow you here. The Docker daemon runs as root (which is kind of inevitable, if you don't then you end up needing hacks like slirp4netns to hook up networking) However, there's nothing innately inside Docker that requires contained processes to run as root. Indeed it's a standard part of recommended Docker security guidance not to run your contained processes as the root user. Docker also provide the facility to enable user namespaces at the daemon level, so that root inside the container != root on the host.
    - zapita 7y ago
      That’s correct. Lxc is not “more secure” than Docker in any meaningful way. They are equivalent in their use of the Linux containment “plumbing”: cgroups, namespaces, capabilities, etc.
      - panpanna 7y ago
        The "plumbing" is the same but they set it up slightly differently which in the end affects things like security. For example user mappings were handled very differently in lxc compared to (earlier versions of) docker. https://linuxcontainers.org/lxc/security/ https://linuxcontainers.org/lxc/security/
      - cyphar 7y ago
        LXC supports user namespaces where containers are isolated from one another. LXD furthers this by remapping containers on restart (so you can change mappings). And you can "punch out" individual mappings for shared volumes and so on. Docker doesn't support this. In fact the recent expansion of the number of mappings allowed by the kernel is work done by Christian Brauner (an LXC maintainer who I collaborate with) -- this feature is so useful to LXC that they had to add the ability to have more mappings. LXC also supports unprivileged operation (which I named "rootless mode"). Docker gained support for this very recently as an experimental feature in 19.03 (still not released), but LXC has supported it (and defaulted to it whenever possible) for years. Though, the Docker one is arguably better in some respects of lack-of-privilege (thanks to great work from Akihiro Suda and Guissupe Scrvano) but it's still new. LXC also has put a lot more work into fundamental security work (both in-kernel and within LXC). Disclaimer: I maintain runc, the runtime Docker uses. There is no question that LXC has better engineering in this department. I collaborate with them quite often, but they have more engineers working on fundamental problems within containers.
- throw2016 7y ago
  LXC is daemonless, there is no process hanging around after the container start, so it starts the container and uses any privileges required to setup things like networking, mounts etc and then drops privileges. LXC had unprivileged container support since 2013 so that part is fairly mature now. 'Unprivileged' in this case means the container process itself is running as a normal user.
  - cyphar 7y ago
    LXC does have a container manager though, which is a single process that stays alive for the life of a single container. Within runc (the runtime Docker uses), we don't have a container manager but the downside is that now the upper level needs to keep alive the descriptors and other kernel objects that allow for safe container management by the runtime. [I maintain runc, and collaborate with the LXC folks.]