7 ms·

Exactly. containers are not secure sandboxes by default and if one is breached all those K8s networking ACLs are worthless.

csmpltn 5y ago
> "Exactly. containers are not secure sandboxes by default and if one is breached all those K8s networking ACLs are worthless." Your suggestion being? Putting a sandbox inside a sandbox? How many layers deep should this be, before being considered "secure"?
- chrisseaton 5y ago
  I don't think this is the bottomless pit that you think it is. A virtualised instance is a lot more secure than a container, and it's probably fine to stop at virtualised instances.
  - csmpltn 5y ago
    A lot more secure? In what ways?
    - chrisseaton 5y ago
      Containers are really a kind of process-isolation - you still share a kernel. You can find a lot of people saying that containers aren’t enough for running untrusted user code. If you run a fully virtualised instance you get your own kernel and aren’t relying on process isolation. Would you be happy if your cloud provider was running your containers on the same virtual I stance as someone else’s? Most people wouldn’t be.
      - csmpltn 5y ago
        The only meaningful difference between breaking out of a process-isolated "container" and a full-blown VM is what's waiting for you outside once you've broken out. Whether it's kernel/OS or a bare metal hypervisor isn't really all that meaningful: exploits and vulnerabilities exist for either. There should be proper hardware-level isolation here, depending on the scenario. Most cloud companies can't afford that though, because they're not rolling out their own hardware.
        chrisseaton 5y ago
        Genuinely, would you be happy with just container isolation between you and other customers of your cloud provider? Most people absolutely would not.
        csmpltn 5y ago
        > "Genuinely, would you be happy with just container isolation between you and other customers of your cloud provider? Most people absolutely would not." But that's exactly how VPS hosting works today - you don't get your own private blade unless you're ready to pay premium prices and have the competence needed to run them yourself. The technicalities of how private resources in a VPS are isolated from each other will differ, but the concept remains the same nonetheless. People bite the bullet, only to be subject to things like rowhammer [1], or other container escape scenarios [2]. The top comment in this thread reflects the proper way of dealing with this: containers or sandboxes are may not be treated as a secure boundary. [1] https://www.usenix.org/conference/usenixsecurity16/technical-sessions/presentation/xiao https://www.usenix.org/conference/usenixsecurity16/technical... [2] https://www.intezer.com/blog/research/how-we-escaped-docker-in-azure-functions/ https://www.intezer.com/blog/research/how-we-escaped-docker-...
        chrisseaton 5y ago
        > But that's exactly how VPS hosting works today No, VPS is isolation by virtualisation, not containerisation. The clue is in the V in the name.
        detaro 5y ago
        No, VPS hosting is not usually container-based today once you leave the utter bargain-bin offers. The difference between VM isolation and container isolation is quite significant.
        staticassertion 5y ago
        > Whether it's kernel/OS or a bare metal hypervisor isn't really all that meaningful: exploits and vulnerabilities exist for either. This is just not true, or at least it's extremely disingenuous. Container isolation relies on the Linux kernel. Other than seccomp-denied syscalls (which aren't a thing in k8s by default) any program in the container has full access to the kernel. The Linux kernel has massive attack surface, especially to root users. VM isolation like Firecracker is much safer. The attack surface is considerably lower. For one thing, you can isolate the process in the guest just as well as you could outside, further limiting attack surface. But more importantly, an attacker either has to attack: 1. Firecracker 2. KVM Both are very small codebases. Firecracker is: 1. Written in Rust. 2. Sandboxed aggressively. KVM has basically never had a public guest to host breakout. You can read about one here, https://googleprojectzero.blogspot.com/2021/06/an-epyc-escape-case-study-of-kvm.html https://googleprojectzero.blogspot.com/2021/06/an-epyc-escap... So, to recap, we have "security boundary relies on a fully exposed Linux kernel" and "security boundary relies on hardened, tiny, security-driven programs". It is not even close. > There should be proper hardware-level isolation here, depending on the scenario. Most cloud companies can't afford that though, because they're not rolling out their own hardware. Hence hardware building hypervisor support in.
    - raesene9 5y ago
      So I'll start by saying that security is always relative and what's ok for one environment won't be for another :) The challenge with Linux containers as used by Docker/Containerd/CRI-O et al, is that containers run against a shared Linux kernel. The Linux kernel has a very large attack surface, so it's easier for attackers to find some way to bypass the restrictions it tries to enforce. If you look at this year there have been several Local Privilege Escalation issues in the Linux Kernel, some of which have allowed for container breakout. If you compare this to a hardened hypervisor (e.g. Firecracker) there is a much smaller attack surface visible from inside the container. It obviously could have a breakout vuln. but there is a lower chance of that occurring.
    - michaelt 5y ago
      Developers working with docker are almost always in the 'docker' group on their local machine, which is functionally equivalent to running everything as root.
      - staticassertion 5y ago
        This doesn't matter if the attacker is in the container. It just means that if the attacker is outside of the container they have a trivial privesc to root on the host.
- kasey_junk 5y ago
  Most serious security teams do not consider containers a security boundary. So it’s not a sandbox inside a sandbox, it’s just a sandbox. Gvisor and firecracker are the most popular sandboxes for containerized workloads.
  - staticassertion 5y ago
    I think this is outdated. Docker is a security boundary. There is no built-in way to get out of a Docker container just by asking by default (if you mount the socket into the container, it's trivial). How good of a boundary it is may be another story. There's some seccomp filters going on and namespacing is pretty sweet too. But an attacker can escape by exploiting the kernel, which I think most security people would consider to be not particularly high effort. So, suitable for internal services that you generally trust, not suitable for hostile code or highly exposed services. In an ideal world maybe we'd all use Firecracker but it's not nearly as easy to do that vs just putting something in a container.
    - TrueDuality 5y ago
      The reason that containers are not generally considered a security boundary is that many of the namespace primitives were _not designed_ as a security layer, they aren't designed to actively reduce the privileges from the current user's context. Since most containers are started as the root user, the namespace transition inherits root's permissions even if they're later dropped. Without SELinux or seccomp restrictions, root can still pretty much do anything to the host even inside the containers. For the most part this is troublesome when parts of the kernel or host userspace code are not fully aware of the different forms of namespacing (there are still portions that just check for an effective UID of 0, without checking whether they're in a namespace for example). These are the components where a lot of container breakouts happen and is largely mitigated by having internal processes in the container not running as root in the namespace. Dropping privileges to a different user still trace's it origin back to the root user on the host, so in some cases being partially aware of namespaces in a section of the kernel or host user code actively hurts the security by tracing the user back to root and using those privileges again. SELinux really tightens the potential to pull these shenanigans, but most production k8s clusters at least that I've seen are built on Ubuntu where those protections aren't available. In this case the security layer is once again SELinux not the namespacing. As long as the container runtime is performing the various namespace isolation primitives starting from the root user these container bypasses are going to be a risk. There are 'rootless' versions of containers which can only use the privileges available to lower (presumably heavily restricted) user but those aren't widely used. Once again this is relying on the security protections of the host user authorization, not on the namespaces. The networking analogy is NAT. People treat it like a security layer as it kind-of-sort-of looks like an ingress firewall since you can't directly address devices inside a NAT, but its not and can be pierced pretty easily. NAT is not a firewall. Namespaces are not a security layer.
- TruthWillHurt 5y ago
  Opposite - don't mess with sandboxing. Use PaaS services like its > 2008, and let AWS / Google security teams harden their platform.

csmpltn 5y ago

> "Exactly. containers are not secure sandboxes by default and if one is breached all those K8s networking ACLs are worthless." Your suggestion being? Putting a sandbox inside a sandbox? How many layers deep should this be, before being considered "secure"?

chrisseaton 5y ago
I don't think this is the bottomless pit that you think it is. A virtualised instance is a lot more secure than a container, and it's probably fine to stop at virtualised instances.
- csmpltn 5y ago
  A lot more secure? In what ways?
  - chrisseaton 5y ago
    Containers are really a kind of process-isolation - you still share a kernel. You can find a lot of people saying that containers aren’t enough for running untrusted user code. If you run a fully virtualised instance you get your own kernel and aren’t relying on process isolation. Would you be happy if your cloud provider was running your containers on the same virtual I stance as someone else’s? Most people wouldn’t be.
    - csmpltn 5y ago
      The only meaningful difference between breaking out of a process-isolated "container" and a full-blown VM is what's waiting for you outside once you've broken out. Whether it's kernel/OS or a bare metal hypervisor isn't really all that meaningful: exploits and vulnerabilities exist for either. There should be proper hardware-level isolation here, depending on the scenario. Most cloud companies can't afford that though, because they're not rolling out their own hardware.
      - chrisseaton 5y ago
        Genuinely, would you be happy with just container isolation between you and other customers of your cloud provider? Most people absolutely would not.
        csmpltn 5y ago
        > "Genuinely, would you be happy with just container isolation between you and other customers of your cloud provider? Most people absolutely would not." But that's exactly how VPS hosting works today - you don't get your own private blade unless you're ready to pay premium prices and have the competence needed to run them yourself. The technicalities of how private resources in a VPS are isolated from each other will differ, but the concept remains the same nonetheless. People bite the bullet, only to be subject to things like rowhammer [1], or other container escape scenarios [2]. The top comment in this thread reflects the proper way of dealing with this: containers or sandboxes are may not be treated as a secure boundary. [1] https://www.usenix.org/conference/usenixsecurity16/technical-sessions/presentation/xiao https://www.usenix.org/conference/usenixsecurity16/technical... [2] https://www.intezer.com/blog/research/how-we-escaped-docker-in-azure-functions/ https://www.intezer.com/blog/research/how-we-escaped-docker-...
        chrisseaton 5y ago
        > But that's exactly how VPS hosting works today No, VPS is isolation by virtualisation, not containerisation. The clue is in the V in the name.
        detaro 5y ago
        No, VPS hosting is not usually container-based today once you leave the utter bargain-bin offers. The difference between VM isolation and container isolation is quite significant.
      - staticassertion 5y ago
        > Whether it's kernel/OS or a bare metal hypervisor isn't really all that meaningful: exploits and vulnerabilities exist for either. This is just not true, or at least it's extremely disingenuous. Container isolation relies on the Linux kernel. Other than seccomp-denied syscalls (which aren't a thing in k8s by default) any program in the container has full access to the kernel. The Linux kernel has massive attack surface, especially to root users. VM isolation like Firecracker is much safer. The attack surface is considerably lower. For one thing, you can isolate the process in the guest just as well as you could outside, further limiting attack surface. But more importantly, an attacker either has to attack: 1. Firecracker 2. KVM Both are very small codebases. Firecracker is: 1. Written in Rust. 2. Sandboxed aggressively. KVM has basically never had a public guest to host breakout. You can read about one here, https://googleprojectzero.blogspot.com/2021/06/an-epyc-escape-case-study-of-kvm.html https://googleprojectzero.blogspot.com/2021/06/an-epyc-escap... So, to recap, we have "security boundary relies on a fully exposed Linux kernel" and "security boundary relies on hardened, tiny, security-driven programs". It is not even close. > There should be proper hardware-level isolation here, depending on the scenario. Most cloud companies can't afford that though, because they're not rolling out their own hardware. Hence hardware building hypervisor support in.
  - raesene9 5y ago
    So I'll start by saying that security is always relative and what's ok for one environment won't be for another :) The challenge with Linux containers as used by Docker/Containerd/CRI-O et al, is that containers run against a shared Linux kernel. The Linux kernel has a very large attack surface, so it's easier for attackers to find some way to bypass the restrictions it tries to enforce. If you look at this year there have been several Local Privilege Escalation issues in the Linux Kernel, some of which have allowed for container breakout. If you compare this to a hardened hypervisor (e.g. Firecracker) there is a much smaller attack surface visible from inside the container. It obviously could have a breakout vuln. but there is a lower chance of that occurring.
  - michaelt 5y ago
    Developers working with docker are almost always in the 'docker' group on their local machine, which is functionally equivalent to running everything as root.
    - staticassertion 5y ago
      This doesn't matter if the attacker is in the container. It just means that if the attacker is outside of the container they have a trivial privesc to root on the host.
kasey_junk 5y ago
Most serious security teams do not consider containers a security boundary. So it’s not a sandbox inside a sandbox, it’s just a sandbox. Gvisor and firecracker are the most popular sandboxes for containerized workloads.
- staticassertion 5y ago
  I think this is outdated. Docker is a security boundary. There is no built-in way to get out of a Docker container just by asking by default (if you mount the socket into the container, it's trivial). How good of a boundary it is may be another story. There's some seccomp filters going on and namespacing is pretty sweet too. But an attacker can escape by exploiting the kernel, which I think most security people would consider to be not particularly high effort. So, suitable for internal services that you generally trust, not suitable for hostile code or highly exposed services. In an ideal world maybe we'd all use Firecracker but it's not nearly as easy to do that vs just putting something in a container.
  - TrueDuality 5y ago
    The reason that containers are not generally considered a security boundary is that many of the namespace primitives were _not designed_ as a security layer, they aren't designed to actively reduce the privileges from the current user's context. Since most containers are started as the root user, the namespace transition inherits root's permissions even if they're later dropped. Without SELinux or seccomp restrictions, root can still pretty much do anything to the host even inside the containers. For the most part this is troublesome when parts of the kernel or host userspace code are not fully aware of the different forms of namespacing (there are still portions that just check for an effective UID of 0, without checking whether they're in a namespace for example). These are the components where a lot of container breakouts happen and is largely mitigated by having internal processes in the container not running as root in the namespace. Dropping privileges to a different user still trace's it origin back to the root user on the host, so in some cases being partially aware of namespaces in a section of the kernel or host user code actively hurts the security by tracing the user back to root and using those privileges again. SELinux really tightens the potential to pull these shenanigans, but most production k8s clusters at least that I've seen are built on Ubuntu where those protections aren't available. In this case the security layer is once again SELinux not the namespacing. As long as the container runtime is performing the various namespace isolation primitives starting from the root user these container bypasses are going to be a risk. There are 'rootless' versions of containers which can only use the privileges available to lower (presumably heavily restricted) user but those aren't widely used. Once again this is relying on the security protections of the host user authorization, not on the namespaces. The networking analogy is NAT. People treat it like a security layer as it kind-of-sort-of looks like an ingress firewall since you can't directly address devices inside a NAT, but its not and can be pierced pretty easily. NAT is not a firewall. Namespaces are not a security layer.
TruthWillHurt 5y ago
Opposite - don't mess with sandboxing. Use PaaS services like its > 2008, and let AWS / Google security teams harden their platform.