5 ms·

> Docker Container Escape > The payload checks for the Docker socket and, if present, attempts container escape through three sequential methods: So even if y

> Docker Container Escape > The payload checks for the Docker socket and, if present, attempts container escape through three sequential methods: So even if you're running devcontainers / VMs, these worms are already trying to escape. Make sure you're running a rootless VM engine (e.g. podman instead of docker) !

jeswin 5mo ago
> Make sure you're running a rootless VM engine (e.g. podman instead of docker) ! Aren't most people running docker rootless (at least on Linux)? Does podman do more?
- Maakuth 5mo ago
  The docker CLI tool is normally executed with user privileges, but there's dockerd, a daemon running as root that actually does the container execution.
  - cyanydeez 5mo ago
    im not sure people understand the security vectors. a user with docker permissions effectively has root permissions. often, docker in docker is used to manage docker orchestration. putinng a user in a docker and peoviding docker access is security through obscurity. on the flip side, i see people blindly installing tools and skills not understanding they are pushing context and capabilities without any significant security features. Imagine mythos is actually exceptional hacker. if you give it a well crafted malicious prompt, its going to even more insecure. the double edged sword is really fascinating to think about
    - jeswin 5mo ago
      Docker has not required root for a long time, at least on Linux. There's even a convenience script for it: https://get.docker.com/rootless https://get.docker.com/rootless Almost everyone I know installs docker rootless.
  - jeswin 5mo ago
    Installing docker doesn't require root. "Rootless mode lets you run the Docker daemon and containers as a non-root user." https://docs.docker.com/engine/security/rootless/ https://docs.docker.com/engine/security/rootless/ This is how docker is best installed on Linux, and there's a convenience script for it as well (https://get.docker.com/rootless https://get.docker.com/rootless). I am surprised that's not how people are using docker.
    - pennomi 5mo ago
      If it’s not default, most people won’t do it.
      - dbacar 4mo ago
        Most poeople even dont know about it.
- mayama 5mo ago
  docker service that sets up containers runs as root. podman does away with that service.
- throw0101c 5mo ago
  > Aren't most people running docker rootless (at least on Linux)? Does podman do more? In the HPC space Apptainer (previously "Singularity") was created precisely due to (multi-)user-level access, especially with the use of NFS.
- perlgeek 5mo ago
  I'd guess that most people who run Docker on linux install it through their distro's package manager, which has a dockerd running as root. On Debian derivatives, you need some kind of extra privs to even talk to it (being a member of the "docker" group, iirc).
moebrowne 5mo ago
Or don't mount the Docker socket into containers
- ErroneousBosh 5mo ago
  Or mount it read-only if you do, like for Traefik.
  - cyphar 5mo ago
    That doesn't actually do anything, connect(2) doesn't need write access to connect to a socket. If you think about it, if that did work then a socket with read-only permissions would be basically useless -- Docker uses HTTP for its API, how would the request for "read-only data" be sent without the ability to send messages? I wrote a comment ~8 years about this[1], I'm kinda sad people still do this and seem to misunderstand just how big of a security hole they are opening... Just don't do it. If you absolutely must then you can configure some very restrictive AuthZ plugin (but those are incredibly fickle and are almost certainly security theatre because they are basically just an application firewall). [1]: https://news.ycombinator.com/item?id=17983623 https://news.ycombinator.com/item?id=17983623
vsgherzi 5mo ago
I really wish we would’ve gotten something more like jails or zones. Or better yet put the containers in a jail or zone. Is there a comprehensive sandbox for Linux like the bsds have?
- Havoc 5mo ago
  Unprivileged LXCs get pretty close. Less unified design wise but on some aspects better - kernel escape doesn’t land you on a 0 UID
  - zenoprax 5mo ago
    > "kernel escape doesn’t land you on a 0 UID" I'm not sure I agree/understand. If you've somehow bypassed AppArmor and cgroup mechanisms then any UID/GID remapping is irrelevant. At this point you're in a position to directly manage memory. What do you mean by "kernel escape"?
    - beardedwizard 5mo ago
      I'm enjoying how nobody in this thread seems to know what a container actually is, and folks may be surprised to learn kernel namespace underpins both docker and lxc.
    - cyphar 5mo ago
      > If you've somehow bypassed AppArmor and cgroup mechanisms then any UID/GID remapping is irrelevant. At this point you're in a position to directly manage memory. Not really, user namespaces (despite all of the issues that unprivileged user namespaces have caused) provide an additional layer of protection as lots of privilege checks are either based on kuid/kgid or are userns-aware. These are some of the deepest security models that Linux has (in the sense that every codepath that involves operating on kernel objects involves a kuid/kgid check and possibly a capability check), so making full use of them is fairly prudent. The vast majority of container breakouts reported over the past decade were complete non-issues or very limited impact if you used user namespaces. AppArmor is not a particularly strong security boundary (it's better than nothing, but there are all sorts of issues with having path-based policies and so they mostly act as final layer of defence against dumb attacks). cgroups are mostly just resource limits, but the devices cgroup (and devices eBPF filter) are are security barrier that prevent obviously bad stuff like direct write access to your host drive. However, those are not the only kinds of protections we need or use in containers, and breaking just those is not enough to "directly manage memory" (but /dev/kmem is inaccessible to user namespaced processes so if that is something you're worried about, user namespaces are another good layer of defence ;)). It should also be noted that LXC is not the only runtime to support this, the OCI ecosystem supports this too and has for quite a long time now (and the latest release of Kubernetes officially supports isolated user namespaces). Most of my container runtime talks in the past decade have had a slide telling people to use user namespaces but sadly they are not widely used yet. On the topic of whether containers are a security boundary, I consider them to be fairly secure these days if you use reasonable defaults (user namespaces, reasonable seccomp rules, ideally non-root inside the container). The main reason we struggle in ways that BSD Jails and Solaris Zones do not is because containers on Linux require putting together a lot of disparate components and while this does mean that you can harden non-container programs using them, it opens the door to more bugs. If we had a way to consolidate more operations and information in-kernel things would be much easier to secure (one perennial issue is that of the inatomicity of switching to the container security zone). (Disclaimer: I am a maintainer of runc.)
cyanydeez 5mo ago
i wish opencode would have a protocol that puts real guardrails around its agents. rather that gaving to try and transplant weve had ssh for decades, surely you can wire a xomms pathway that cant deciate.
mentalgear 5mo ago
You may run > podman info --format '{{.Host.Security.Rootless}}' to ensure podman is rootless in your config.
matheusmoreira 5mo ago
Why not run a proper virtual machine?
- agrounds 5mo ago
  I dunno, why own a car when you could ride your bike instead? They’re just different things and people may choose to use one over the other for a variety of reasons.
- waz0wski 5mo ago
  That's the direction container runtimes are trending Amazon has been doing it with Firecracker for a while and Kata containers is another popular one https://github.com/firecracker-microvm/firecracker https://github.com/firecracker-microvm/firecracker https://github.com/kata-containers/kata-containers https://github.com/kata-containers/kata-containers
  - anygivnthursday 5mo ago
    I think Google took a different approach with gVisor and limited userspace kernel interface, tradeoffs...
  - matheusmoreira 5mo ago
    I did the same. Claude coded my own solution. https://github.com/matheusmoreira/virtdev https://github.com/matheusmoreira/virtdev It's been working really well. Use it every day. Just make some machines and ssh in.
- throw0101c 5mo ago
  > Why not run a proper virtual machine? Extra 'overhead' and heaviness (perceived or real).
- ahknight 5mo ago
  The joys of running podman/docker on macOS: you can't help but run it in a hypervisor.
mapontosevenths 5mo ago
Despite what some people will tell you (including many in the security indistry), Docker is not a strong security boundary, and it should not be treated as one. It shares a kernel with the running system. It reminds me of the good old days when people would hand out low privilege Linux accounts and rely on the kernel to prevent privilige escalation. Docker is literally the same thing, just with extra steps. Especially today with new kernel LPE'S dropping every 5 minutes. Yes, Podman is a bit better because you arent handing the attacker root, but... why hand them an account at all? Just use a grown up VM.
- zenoprax 5mo ago
  [dead]
- beardedwizard 5mo ago
  Yeah because I'd rather trade one kernel surface for another.
- throw0101c 5mo ago
  > Despite what some people will tell you (including many in the security indistry), Docker is not a strong security boundary, and it should not be treated as one. It shares a kernel with the running system. Solaris Zones and FreeBSD Jails (their inspiration) also share a kernel with the running system and do not seem to have as many escape vulnerabilities. (Though partly because there may not be as much scrutiny of course.)
  - Icathian 5mo ago
    Yeah, I'm reminded of 15 years ago being told Linux was super secure because people were popping Windows all the time. Turns out it was mostly just a function of effort pointed at the target, and I don't have any reason to believe that's not the case here too.
    - ErroneousBosh 5mo ago
      Linux has had 100% market penetration for 20 years or so now. Everyone using a computer uses Linux *somewhere* in it. You'd think if it was that easy, there would be exploits all over the place. Why isn't every single desk phone and router part of a botnet?
evertheylen 5mo ago
I rely on podman for my "devcontainers": https://github.com/evertheylen/probox https://github.com/evertheylen/probox. If anyone can point me to the weak points in my setup I'd appreciate it!

jeswin 5mo ago

> Make sure you're running a rootless VM engine (e.g. podman instead of docker) ! Aren't most people running docker rootless (at least on Linux)? Does podman do more?

Maakuth 5mo ago
The docker CLI tool is normally executed with user privileges, but there's dockerd, a daemon running as root that actually does the container execution.
- cyanydeez 5mo ago
  im not sure people understand the security vectors. a user with docker permissions effectively has root permissions. often, docker in docker is used to manage docker orchestration. putinng a user in a docker and peoviding docker access is security through obscurity. on the flip side, i see people blindly installing tools and skills not understanding they are pushing context and capabilities without any significant security features. Imagine mythos is actually exceptional hacker. if you give it a well crafted malicious prompt, its going to even more insecure. the double edged sword is really fascinating to think about
  - jeswin 5mo ago
    Docker has not required root for a long time, at least on Linux. There's even a convenience script for it: https://get.docker.com/rootless https://get.docker.com/rootless Almost everyone I know installs docker rootless.
- jeswin 5mo ago
  Installing docker doesn't require root. "Rootless mode lets you run the Docker daemon and containers as a non-root user." https://docs.docker.com/engine/security/rootless/ https://docs.docker.com/engine/security/rootless/ This is how docker is best installed on Linux, and there's a convenience script for it as well (https://get.docker.com/rootless https://get.docker.com/rootless). I am surprised that's not how people are using docker.
  - pennomi 5mo ago
    If it’s not default, most people won’t do it.
    - dbacar 4mo ago
      Most poeople even dont know about it.
mayama 5mo ago
docker service that sets up containers runs as root. podman does away with that service.
throw0101c 5mo ago
> Aren't most people running docker rootless (at least on Linux)? Does podman do more? In the HPC space Apptainer (previously "Singularity") was created precisely due to (multi-)user-level access, especially with the use of NFS.
perlgeek 5mo ago
I'd guess that most people who run Docker on linux install it through their distro's package manager, which has a dockerd running as root. On Debian derivatives, you need some kind of extra privs to even talk to it (being a member of the "docker" group, iirc).

moebrowne 5mo ago

Or don't mount the Docker socket into containers

ErroneousBosh 5mo ago
Or mount it read-only if you do, like for Traefik.
- cyphar 5mo ago
  That doesn't actually do anything, connect(2) doesn't need write access to connect to a socket. If you think about it, if that did work then a socket with read-only permissions would be basically useless -- Docker uses HTTP for its API, how would the request for "read-only data" be sent without the ability to send messages? I wrote a comment ~8 years about this[1], I'm kinda sad people still do this and seem to misunderstand just how big of a security hole they are opening... Just don't do it. If you absolutely must then you can configure some very restrictive AuthZ plugin (but those are incredibly fickle and are almost certainly security theatre because they are basically just an application firewall). [1]: https://news.ycombinator.com/item?id=17983623 https://news.ycombinator.com/item?id=17983623

vsgherzi 5mo ago

I really wish we would’ve gotten something more like jails or zones. Or better yet put the containers in a jail or zone. Is there a comprehensive sandbox for Linux like the bsds have?

Havoc 5mo ago
Unprivileged LXCs get pretty close. Less unified design wise but on some aspects better - kernel escape doesn’t land you on a 0 UID
- zenoprax 5mo ago
  > "kernel escape doesn’t land you on a 0 UID" I'm not sure I agree/understand. If you've somehow bypassed AppArmor and cgroup mechanisms then any UID/GID remapping is irrelevant. At this point you're in a position to directly manage memory. What do you mean by "kernel escape"?
  - beardedwizard 5mo ago
    I'm enjoying how nobody in this thread seems to know what a container actually is, and folks may be surprised to learn kernel namespace underpins both docker and lxc.
  - cyphar 5mo ago
    > If you've somehow bypassed AppArmor and cgroup mechanisms then any UID/GID remapping is irrelevant. At this point you're in a position to directly manage memory. Not really, user namespaces (despite all of the issues that unprivileged user namespaces have caused) provide an additional layer of protection as lots of privilege checks are either based on kuid/kgid or are userns-aware. These are some of the deepest security models that Linux has (in the sense that every codepath that involves operating on kernel objects involves a kuid/kgid check and possibly a capability check), so making full use of them is fairly prudent. The vast majority of container breakouts reported over the past decade were complete non-issues or very limited impact if you used user namespaces. AppArmor is not a particularly strong security boundary (it's better than nothing, but there are all sorts of issues with having path-based policies and so they mostly act as final layer of defence against dumb attacks). cgroups are mostly just resource limits, but the devices cgroup (and devices eBPF filter) are are security barrier that prevent obviously bad stuff like direct write access to your host drive. However, those are not the only kinds of protections we need or use in containers, and breaking just those is not enough to "directly manage memory" (but /dev/kmem is inaccessible to user namespaced processes so if that is something you're worried about, user namespaces are another good layer of defence ;)). It should also be noted that LXC is not the only runtime to support this, the OCI ecosystem supports this too and has for quite a long time now (and the latest release of Kubernetes officially supports isolated user namespaces). Most of my container runtime talks in the past decade have had a slide telling people to use user namespaces but sadly they are not widely used yet. On the topic of whether containers are a security boundary, I consider them to be fairly secure these days if you use reasonable defaults (user namespaces, reasonable seccomp rules, ideally non-root inside the container). The main reason we struggle in ways that BSD Jails and Solaris Zones do not is because containers on Linux require putting together a lot of disparate components and while this does mean that you can harden non-container programs using them, it opens the door to more bugs. If we had a way to consolidate more operations and information in-kernel things would be much easier to secure (one perennial issue is that of the inatomicity of switching to the container security zone). (Disclaimer: I am a maintainer of runc.)

cyanydeez 5mo ago

i wish opencode would have a protocol that puts real guardrails around its agents. rather that gaving to try and transplant weve had ssh for decades, surely you can wire a xomms pathway that cant deciate.

mentalgear 5mo ago

You may run > podman info --format '{{.Host.Security.Rootless}}' to ensure podman is rootless in your config.

matheusmoreira 5mo ago

Why not run a proper virtual machine?

agrounds 5mo ago
I dunno, why own a car when you could ride your bike instead? They’re just different things and people may choose to use one over the other for a variety of reasons.
waz0wski 5mo ago
That's the direction container runtimes are trending Amazon has been doing it with Firecracker for a while and Kata containers is another popular one https://github.com/firecracker-microvm/firecracker https://github.com/firecracker-microvm/firecracker https://github.com/kata-containers/kata-containers https://github.com/kata-containers/kata-containers
- anygivnthursday 5mo ago
  I think Google took a different approach with gVisor and limited userspace kernel interface, tradeoffs...
- matheusmoreira 5mo ago
  I did the same. Claude coded my own solution. https://github.com/matheusmoreira/virtdev https://github.com/matheusmoreira/virtdev It's been working really well. Use it every day. Just make some machines and ssh in.
throw0101c 5mo ago
> Why not run a proper virtual machine? Extra 'overhead' and heaviness (perceived or real).
ahknight 5mo ago
The joys of running podman/docker on macOS: you can't help but run it in a hypervisor.

mapontosevenths 5mo ago

Despite what some people will tell you (including many in the security indistry), Docker is not a strong security boundary, and it should not be treated as one. It shares a kernel with the running system. It reminds me of the good old days when people would hand out low privilege Linux accounts and rely on the kernel to prevent privilige escalation. Docker is literally the same thing, just with extra steps. Especially today with new kernel LPE'S dropping every 5 minutes. Yes, Podman is a bit better because you arent handing the attacker root, but... why hand them an account at all? Just use a grown up VM.

zenoprax 5mo ago
[dead]
beardedwizard 5mo ago
Yeah because I'd rather trade one kernel surface for another.
throw0101c 5mo ago
> Despite what some people will tell you (including many in the security indistry), Docker is not a strong security boundary, and it should not be treated as one. It shares a kernel with the running system. Solaris Zones and FreeBSD Jails (their inspiration) also share a kernel with the running system and do not seem to have as many escape vulnerabilities. (Though partly because there may not be as much scrutiny of course.)
- Icathian 5mo ago
  Yeah, I'm reminded of 15 years ago being told Linux was super secure because people were popping Windows all the time. Turns out it was mostly just a function of effort pointed at the target, and I don't have any reason to believe that's not the case here too.
  - ErroneousBosh 5mo ago
    Linux has had 100% market penetration for 20 years or so now. Everyone using a computer uses Linux *somewhere* in it. You'd think if it was that easy, there would be exploits all over the place. Why isn't every single desk phone and router part of a botnet?

evertheylen 5mo ago

I rely on podman for my "devcontainers": https://github.com/evertheylen/probox https://github.com/evertheylen/probox. If anyone can point me to the weak points in my setup I'd appreciate it!