5 ms·

Containers are not a security boundary. Containers are not a security boundary. Containers are not a security boundary. Any system that treats them as such i

by paxys 3y ago

Containers are not a security boundary. Containers are not a security boundary. Containers are not a security boundary. Any system that treats them as such is inherently compromised.

insanitybit 3y ago
Containers are absolutely a security boundary, and an excellent one at that - at least, Docker containers are. 1. You get file, process, and network namespaces, which are a security boundary 2. You get a seccomp filter, which is a security boundary The "containers are not a security boundary" meme needs to die. Elsewhere you mention that "containers are not sufficient for untrusted code" but that's a very specific and very niche threat model. Most people don't say "send me a binary and I'll execute it", or have arbitrary RCE + multitenancy concerns. Containers aren't sufficient for multi-tenant RCE because the RCE is by design so 100% of your security pressure is on the container at that point. In the vast majority of cases you're dealing with servers that don't intend to allow arbitrary code execution, and containers are an extremely easy way to drive up the cost of an attack given that the attacker has already spent a lot of time and money on the RCE. SELinux is also not sufficient for the "RCE by design" threat model - is SELinux not a security boundary? Further, containers can limit the impact of remote vulnerabilities like path traversal attacks, since they have file isolation by default. edit: I see elsewhere that there's a real lack of clarity here. First off, a security boundary can be meaningfully defined as a limitation on an attacker that does not have a way around it without additional exploitation. So the main reason why people have said "containers are not a security boundary" is because: a) Very, very early on, escaping a container was trivial - like you could just ask to leave and you'd be out. b) There were some blog posts basically saying "containers aren't sufficient for multi-tenancy" where arbitrary users can run arbitrary code on the same host. This is still the case today - but it's also an extremely rare threat model. Why would containers not be sufficient for (b) ? Because the majority of the Linux kernel is still exposed to the attacker within a container - the vast majority of system call interfaces are exposed (but seccomp removes a number of these, which is nice). The Linux kernel is not at all sufficiently hardened against attackers who can make arbitrary system calls, therefor containers are not sufficient against those attackers. If you give the attacker RCE by default (ie: your service is "Send me a binary and i'll run it") then an attacker can spend all of their time and money just on a local privesc, which isn't crazy difficult. Since the cost of RCE in an RCE-aaS is 0 the consensus is that containers aren't strong enough for RCE-aaS threat models. In that case use Firecracker or gVisor or a dedicated host. Otherwise, RCE costs tend to be pretty high and having to develop an additional LPE on top of one is, at minimum, quite a pain for many attackers. Containers are extremely easy to deploy software into, something like a Firecracker VM is not. Containers are basically just processes, so you can monitor them and manage them trivially. Monitoring and managing VMs with processes inside of them is obviously harder. So I think the 'bang for your buck' with containers is extremely solid.
rjzzleep 3y ago
They were on Solaris no?
carbotaniuman 3y ago
What is the security boundary then? Everywhere I read treats them as a security boundary for say, untrusted code.
- openasocket 3y ago
  Virtual machines can be considered a security boundary. Containers are absolutely not.
  - dvt 3y ago
    The distinction is getting more and more fuzzy, so this is almost a meaningless point (as is GGP). It's very vendor-specific, let alone that I'm pretty sure Spectre attacks can work across VMs.
    - openasocket 3y ago
      I wouldn’t consider the distinction “fuzzy”. Assuming we’re talking Linux (I don’t know about the Mac and Windows world) containers are implemented using namespaces and cgroups, and always have been. Whether you are talking docker, containerd, some more minimalistic thing built on runc, it’s all Linux namespaces and cgroups. And those things were explicitly not designed to act as security boundaries when running untrusted code.
      - deleted 3y ago
        [deleted]
      - zokier 3y ago
        Kata containers would like a word
        yjftsjthsd-h 3y ago
        Now in fairness, that is very specifically using a VM to add an even stronger boundry; it's not really the same thing.
2OEH8eoCRo0 3y ago
Of course they are. There is debate over how good of a boundary they are but even caution tape is a security boundary.
johncolanduoni 3y ago
This is true, but the exploits listed in this article are poor evidence of this. If it was as simple as not giving Linux containers any capabilities or host sockets they would be a decent security boundary. I find it super frustrating that we're stuck with kernels with inherent weaknesses to their security approach that we have to re-implement them in userspace in one way or another (gVisor, Firecracker, etc.) just to get the hardware-provided userspace/kernel boundary to work properly.
10000truths 3y ago
This kind of reductive dogma is meaningless FUD. A container is as secure as its underlying implementation.
imetatroll 3y ago
Is gvisor considered sufficient when running 3rd-party code? Are there other measures that should be taken in addition to using gvisor?
brutal_chaos_ 3y ago
A container is a security boundry. However, no security boundry is perfect and more boundries must be put in place as well, depending on your threat model. edit: typo
harporoeder 3y ago
All of these escapes rely on some obvious explicit reduction of the isolation guarantees. If you know how to escape a simple docker container invoked with default parameters such as `docker run --rm -it ubuntu /bin/bash` I'm sure many people would be interested.
- paxys 3y ago
  "Escapes" is a vaguely defined term, but considering basic escalation of privilege: - Networking is the obvious one in this scenario. By default (on Docker/LXC/others) all containers are on the same virtual bridge and can communicate with each other. Even with some additional configuration and isolation it is possible to MITM attack other containers on the same host. - It is very easy to DDoS adjacent containers e.g. by spamming signals, forking new processes, creating files. There is again no default safeguard against this.
  - charcircuit 3y ago
    If you give a container access to the network, then yes it will have access to the network. That isn't an escape. cgroups can prevent containers from using too much memory or cpu
    - im3w1l 3y ago
      I think we must be careful not to use no-true-scotsman here. Imo, an attack should be considered valid if it works against a typical config - one you would arrive at following a popular tutorial, rather than requiring that it must work against an ideal config.
      - charcircuit 3y ago
        The definition of escaping a container (namespace) is being able to interact with resources not in the namespaces of the process. If a process's network namespace contains a network device then it is not an escape to use it by definition. If the network namespace for a process contains no devices then being able to use a network device would be an escape.
ajross 3y ago
Is putting processes in separate memory spaces not a security boundary to you? Isolating separate app responsibilities in separate UIDs? Filesystem permission bits? All those are "weaker" boundaries than containers. Do you really claim that these have ZERO security value? That's silly. Of course containers are a security boundary. They have advantages and disadvantages. Treat them as tools and not slogans.
SoftTalker 3y ago
> Containers are not a security boundary. The name is at least misleading if not wrong, then? What do they "contain"?
- Kluggy 3y ago
  They contain the transitive closure of software and libraries to run a binary. Under the hood, they're a fancy wrapper around a pile of tar files. Tar files certainly contain other files and are also not a security boundary.

by paxys 3y ago

Containers are not a security boundary. Containers are not a security boundary. Containers are not a security boundary. Any system that treats them as such is inherently compromised.

insanitybit 3y ago

Containers are absolutely a security boundary, and an excellent one at that - at least, Docker containers are. 1. You get file, process, and network namespaces, which are a security boundary 2. You get a seccomp filter, which is a security boundary The "containers are not a security boundary" meme needs to die. Elsewhere you mention that "containers are not sufficient for untrusted code" but that's a very specific and very niche threat model. Most people don't say "send me a binary and I'll execute it", or have arbitrary RCE + multitenancy concerns. Containers aren't sufficient for multi-tenant RCE because the RCE is by design so 100% of your security pressure is on the container at that point. In the vast majority of cases you're dealing with servers that don't intend to allow arbitrary code execution, and containers are an extremely easy way to drive up the cost of an attack given that the attacker has already spent a lot of time and money on the RCE. SELinux is also not sufficient for the "RCE by design" threat model - is SELinux not a security boundary? Further, containers can limit the impact of remote vulnerabilities like path traversal attacks, since they have file isolation by default. edit: I see elsewhere that there's a real lack of clarity here. First off, a security boundary can be meaningfully defined as a limitation on an attacker that does not have a way around it without additional exploitation. So the main reason why people have said "containers are not a security boundary" is because: a) Very, very early on, escaping a container was trivial - like you could just ask to leave and you'd be out. b) There were some blog posts basically saying "containers aren't sufficient for multi-tenancy" where arbitrary users can run arbitrary code on the same host. This is still the case today - but it's also an extremely rare threat model. Why would containers not be sufficient for (b) ? Because the majority of the Linux kernel is still exposed to the attacker within a container - the vast majority of system call interfaces are exposed (but seccomp removes a number of these, which is nice). The Linux kernel is not at all sufficiently hardened against attackers who can make arbitrary system calls, therefor containers are not sufficient against those attackers. If you give the attacker RCE by default (ie: your service is "Send me a binary and i'll run it") then an attacker can spend all of their time and money just on a local privesc, which isn't crazy difficult. Since the cost of RCE in an RCE-aaS is 0 the consensus is that containers aren't strong enough for RCE-aaS threat models. In that case use Firecracker or gVisor or a dedicated host. Otherwise, RCE costs tend to be pretty high and having to develop an additional LPE on top of one is, at minimum, quite a pain for many attackers. Containers are extremely easy to deploy software into, something like a Firecracker VM is not. Containers are basically just processes, so you can monitor them and manage them trivially. Monitoring and managing VMs with processes inside of them is obviously harder. So I think the 'bang for your buck' with containers is extremely solid.

rjzzleep 3y ago

They were on Solaris no?

carbotaniuman 3y ago

What is the security boundary then? Everywhere I read treats them as a security boundary for say, untrusted code.

openasocket 3y ago
Virtual machines can be considered a security boundary. Containers are absolutely not.
- dvt 3y ago
  The distinction is getting more and more fuzzy, so this is almost a meaningless point (as is GGP). It's very vendor-specific, let alone that I'm pretty sure Spectre attacks can work across VMs.
  - openasocket 3y ago
    I wouldn’t consider the distinction “fuzzy”. Assuming we’re talking Linux (I don’t know about the Mac and Windows world) containers are implemented using namespaces and cgroups, and always have been. Whether you are talking docker, containerd, some more minimalistic thing built on runc, it’s all Linux namespaces and cgroups. And those things were explicitly not designed to act as security boundaries when running untrusted code.
    - deleted 3y ago
      [deleted]
    - zokier 3y ago
      Kata containers would like a word
      - yjftsjthsd-h 3y ago
        Now in fairness, that is very specifically using a VM to add an even stronger boundry; it's not really the same thing.

2OEH8eoCRo0 3y ago

Of course they are. There is debate over how good of a boundary they are but even caution tape is a security boundary.

johncolanduoni 3y ago

This is true, but the exploits listed in this article are poor evidence of this. If it was as simple as not giving Linux containers any capabilities or host sockets they would be a decent security boundary. I find it super frustrating that we're stuck with kernels with inherent weaknesses to their security approach that we have to re-implement them in userspace in one way or another (gVisor, Firecracker, etc.) just to get the hardware-provided userspace/kernel boundary to work properly.

10000truths 3y ago

This kind of reductive dogma is meaningless FUD. A container is as secure as its underlying implementation.

imetatroll 3y ago

Is gvisor considered sufficient when running 3rd-party code? Are there other measures that should be taken in addition to using gvisor?

brutal_chaos_ 3y ago

A container is a security boundry. However, no security boundry is perfect and more boundries must be put in place as well, depending on your threat model. edit: typo

harporoeder 3y ago

All of these escapes rely on some obvious explicit reduction of the isolation guarantees. If you know how to escape a simple docker container invoked with default parameters such as `docker run --rm -it ubuntu /bin/bash` I'm sure many people would be interested.

paxys 3y ago
"Escapes" is a vaguely defined term, but considering basic escalation of privilege: - Networking is the obvious one in this scenario. By default (on Docker/LXC/others) all containers are on the same virtual bridge and can communicate with each other. Even with some additional configuration and isolation it is possible to MITM attack other containers on the same host. - It is very easy to DDoS adjacent containers e.g. by spamming signals, forking new processes, creating files. There is again no default safeguard against this.
- charcircuit 3y ago
  If you give a container access to the network, then yes it will have access to the network. That isn't an escape. cgroups can prevent containers from using too much memory or cpu
  - im3w1l 3y ago
    I think we must be careful not to use no-true-scotsman here. Imo, an attack should be considered valid if it works against a typical config - one you would arrive at following a popular tutorial, rather than requiring that it must work against an ideal config.
    - charcircuit 3y ago
      The definition of escaping a container (namespace) is being able to interact with resources not in the namespaces of the process. If a process's network namespace contains a network device then it is not an escape to use it by definition. If the network namespace for a process contains no devices then being able to use a network device would be an escape.

ajross 3y ago

Is putting processes in separate memory spaces not a security boundary to you? Isolating separate app responsibilities in separate UIDs? Filesystem permission bits? All those are "weaker" boundaries than containers. Do you really claim that these have ZERO security value? That's silly. Of course containers are a security boundary. They have advantages and disadvantages. Treat them as tools and not slogans.

SoftTalker 3y ago

> Containers are not a security boundary. The name is at least misleading if not wrong, then? What do they "contain"?

Kluggy 3y ago
They contain the transitive closure of software and libraries to run a binary. Under the hood, they're a fancy wrapper around a pile of tar files. Tar files certainly contain other files and are also not a security boundary.