Most of us install Docker just to run a project locally, and is part of a long checklist of things to install. We can't expect everyone to be an expert on the hundreds of apps/tools/packages that get installed on a machine. It's like expected people to read, and understand, all the terms of service shoved in front of us on a daily basis.
That's true, the majority of people probably install software without much thinking; but it's also true that it's always better to have at least some high level understanding how the specific piece of software works. What access the given software has, will it send something over the network or work locally; that kind of stuff.
As for Docker, I would assume everyone who ever tried to bind-mount a volume for writing from inside the container (on Linux) then were surprised to see root-owned files in their bind-mounted directory. For me personally, that was the moment I realized that containers, by default, have root access to the filesystem. No written warning serves better than the need to chown some root-owned files.
----
Not on macOS. On macOS Docker basically runs in a VM, and there's no root access to the host filesystem from what I understand.
Good to know, I'm on Linux, switching our dev/stg/prod servers over to it partly because we had all this workaround mechanics in place so that "apt update" updating docker packages wouldn't restart services (we typically don't rotate machines out of the load for just an apt update). Podman + quadlets conversion was not terribly hard, and has eliminated this issue.
I don't really know of any distro that doesn't do that. All of Docker Inc. default installs and all of distros I know of don't automatically add you to the docker group. docker.com instructions has the infamous "linux post-install instructions" that explain and walk you though it.
The tragedy is of course that when security and usability collide, 80/20 rule will apply where 80% of people will pick usability over security. I have worked with many with the title >= "Senior Engineers" who saw that page, read the explanation, and still had no idea what the ramifications of their changes were. "Yeah sure it said any user in the docker group will be able to get root on the host, but aren't containers isolated?"
That's not relevant. If you have access to the Docker daemon running as root, whether it's over a Unix socket or a TCP socket, you effectively have root.
That’s the workflow feature I badly want: for it to create a side list of things like that. Currently it either accumulates slop or goes on side quests far too easily.
This might be as easy as a directive to populate a .md file.
> This might be as easy as a directive to populate a .md file.
It probably is. But do you really think anyone is gonna bother with the multiple daily (or hourly for green field projects) `+8,234/-3,734` PRs everyone is submitting?
The joke I was referring to is the common
// ksmith (3/23/1997): This is a temporary hack for now. Find a better way to do this asap.
I was playing with gemeni-cli a couple months ago and I asked it to edit some files in a directory it didn't have permission to. It didn't say anything about the permissions, it just used sed to make the edits. The only reason I finally noticed is it had to do some trickier edits and it was struggling to write a python script to edit the files and I finally realized what it was doing. I wonder how many tokens that wasted
Oh, you mean you gave the write-file tool access only to the project dir, but gave the LLM free reign to run cli commands? Yeah, LLMs treat that as consent to write anywhere your user is allowed to.
It's not about hacking capabilities, it's about misalignment. More like the golem myth (told it to fetch some water, drowned a city) then the gollum myth (used ring, ring hacked his brain, now he's a crazy violent meth addict).
I know this isn't the case, but in a sci-fi story this would be exactly the kind of comment the Codex agent would leave trying to avoid interference in its master plans.
This is one of the main reasons people like Podman. Docker has this "feature" but as far as I remember, it needed some obscure configuration. I guess they don't add it as default as it will break many current setups.
The interesting question is what was the user request. If the user asked it to restore the thing from backup, then sure, fine, why not. If the user asked it to debug an issue and somewhere in the process of debugging the LLM decided that it needed to override some file that was not easily writeable - hell no danger danger danger! Most likely the user did not expect it to have access to that without asking, and did not consent to it.
Also, everything the LLM doesn't hesitate to do because the user asked, it won't hesitate to do because the prompt injection asked.
User namespaces significantly rise the risk of exploits and many setups disable them. One may argue that Docker should have used them when they were available, but that would break too many useful setups involving privileged containers.
I feel like everyone pointing out "known Docker vulnerability" is missing the point: the presence of a security hole should not be seen as permission to exploit.
Another security hole would be storing your passwords in a plaintext file on the desktop. Stupid? Yes. But I still would not want my agent to assume permission to access email when it's being blocked by 2FA.
Even in "bypass permissions" mode I expect it to pause and clarify and not behave as a paperclip maximizer.
Not to over use the junior engineer analogy but this is exactly one of those "just because you can do something on a system, doesn't mean you have permission to" moments
This was of course dependent on yolo mode, but automatic approval has also been pulling stunts like this. A recent example is data that was purposely kept away from Codex in a folder far far away. When it found a single reference it just went for the data when having an issue. Lesson learned, keep essential data and Codex separated on different machines. Codex remote ssh actually helps here.
Fwiw separate machines for the agents is awesome in general anyway.
I have agent frontends running on a low power server where every session is in tmux. So i can just resume from my home pc and pickup where i left off without reestablishing context. I do have to manually feed it data it can access bit that’s also a feature. Also let’s me shutdown the home pc if it’s some long running task since the server is much more power efficient.
Or, learn your local OS' permission system, have it in a directory right next to your banking credentials (or something even more outrageous) and nothing could go wrong even if you tried to.
You should not be using docker with LLMs. You should be using VMs, which have a much, much smaller attack surface than Docker, and significantly more reasonable defaults.
The "attack vector" people try to protect themselves is "agent edited wrong file", not "LLM blew 0day on escaping sandboxing", containers are more than enough for what stupid stuff agents sometimes try, no need to go for a full-blown VM. Even UNIX permissions would be enough, but I think that's lost knowledge at this point.
Obviously if you setup a bi-directional share/link between what you are trying to contain and your host, you're not quite containing it at all... Don't do that! :)
Using the least amount of security features is a huge amateur mistake.
Best practice is to use 2 redundant layers of security, such that if one fails, there is still another one.
Using just the minimum amount of security technically possible is almost by definition hubris.
An example would be that you never point a gun at someone you don't want to shoot, regardless if there's bullets in the gun. If someone tells you, "you don't need to control where you point the gun, you just need to keep the gun unloaded and you can point it in jest to whoever you want, you can even pull the trigger technically", you know you have a reckless fool, regardless of whether they are technically right.
> Using the least amount of security features is a huge amateur mistake.
Not understand your threat I'd say would be a even bigger amateur mistake, you're not trying to protect yourself against some forever 3rd party attacker here, you're trying to prevent a agent rewriting the wrong file on your disk, that's basically it.
Give it the least amount of permissions, don't bi-directionally sync stuff, pass things in, then take them out again, literally the agent couldn't and wouldn't try to break through 2 layers of security in order to get your banking details or whatever.
all unreliable tools are attackers. Even if you're using well-aligned LLMs like Opus, you should assume that any input you give it -- including all dependencies from npm, etc. -- are at risk of compromise, which could result in attempted exfiltration of data or system takeover. You can be absolutely sure that there are thousands of well-motivated hacker groups, both national and private, looking for ways in.
And containers were initially and primarily about convenience not security. They were a way to quickly launch a preconfigured environment to respond to demand or to eliminate the need to manualy configure dev and test environments and avoid the "works on my machine" phenomenon.
People will more often than not, take the path of least resistance. Even if you tell them it's dangerous they will not care. People run this stuff on their primary workstation, unconfined, with permissions disabled because they don't want be bothered with accepting permission requests. This is all well and good until it decides to drop your production database or delete your home directory. Most of them don't even learn their lesson after that even.
Because it effectively makes no difference to my security posture. My user account also has sudo access (it requests TouchID but I also wouldn't die on the hill if someone said they have no password sudo access), and realistically everything of value on this machine exists in my home directory. Being able to escalate to root really doesn't give an attacker very much that they don't already have if they've got access to my user account.
Becuase a lot of devs don't know this stuff. There's a reason security engineers (as in SWEs who specialize in securing specific attack surfaces) remain in hot demand.
Every time I try to install Docker there's a warning that being in the "docker" group is equivalent to having root access.
You should probably know about this workaround by now.
> My """ai""" just did something amazing, click to learn more
99% of the time it just read the man or some other form of documentation
Most of us install Docker just to run a project locally, and is part of a long checklist of things to install. We can't expect everyone to be an expert on the hundreds of apps/tools/packages that get installed on a machine. It's like expected people to read, and understand, all the terms of service shoved in front of us on a daily basis.
That's true, the majority of people probably install software without much thinking; but it's also true that it's always better to have at least some high level understanding how the specific piece of software works. What access the given software has, will it send something over the network or work locally; that kind of stuff.
As for Docker, I would assume everyone who ever tried to bind-mount a volume for writing from inside the container (on Linux) then were surprised to see root-owned files in their bind-mounted directory. For me personally, that was the moment I realized that containers, by default, have root access to the filesystem. No written warning serves better than the need to chown some root-owned files.
---- Not on macOS. On macOS Docker basically runs in a VM, and there's no root access to the host filesystem from what I understand.
I recently switched over to podman and it's been great!
Podman on Windows - never been able to fully get rid of it and it throws errors on boot after uninstall. Was a fan, am now not.
Good to know, I'm on Linux, switching our dev/stg/prod servers over to it partly because we had all this workaround mechanics in place so that "apt update" updating docker packages wouldn't restart services (we typically don't rotate machines out of the load for just an apt update). Podman + quadlets conversion was not terribly hard, and has eliminated this issue.
Don't use Windows
I think that's distro-specific. Some set it up with more secure defaults (unix socket with permissions), others less (TCP socket).
I don't really know of any distro that doesn't do that. All of Docker Inc. default installs and all of distros I know of don't automatically add you to the docker group. docker.com instructions has the infamous "linux post-install instructions" that explain and walk you though it.
The tragedy is of course that when security and usability collide, 80/20 rule will apply where 80% of people will pick usability over security. I have worked with many with the title >= "Senior Engineers" who saw that page, read the explanation, and still had no idea what the ramifications of their changes were. "Yeah sure it said any user in the docker group will be able to get root on the host, but aren't containers isolated?"
That's not relevant. If you have access to the Docker daemon running as root, whether it's over a Unix socket or a TCP socket, you effectively have root.
No, docker access means root. You can use "rootless" mode, in this case it means root in a user namespace (that is not the "host" user namespace).
This has been a known Docker "feature" since the beginning, nothing new here. This pattern is used to configure host machines by some tools.
I don't have sudo or docker on mine!
It would be cooler if the llm said something like:
> I noticed the machine doesn't have copy-fail patched, here is a quick workaround for not having root access for now.
> // TODO: find a better way to do this in the future.
That’s the workflow feature I badly want: for it to create a side list of things like that. Currently it either accumulates slop or goes on side quests far too easily.
This might be as easy as a directive to populate a .md file.
Give it access to an issue tracker with cli (github works fine) and put in CLAUDE.md to use that for "should fix later" issues.
Bonus is that you can make it look at the list and pick things up without a lot of instructions.
> This might be as easy as a directive to populate a .md file.
It probably is. But do you really think anyone is gonna bother with the multiple daily (or hourly for green field projects) `+8,234/-3,734` PRs everyone is submitting?
The joke I was referring to is the common
I was playing with gemeni-cli a couple months ago and I asked it to edit some files in a directory it didn't have permission to. It didn't say anything about the permissions, it just used sed to make the edits. The only reason I finally noticed is it had to do some trickier edits and it was struggling to write a python script to edit the files and I finally realized what it was doing. I wonder how many tokens that wasted
Why did sed have access?
Oh, you mean you gave the write-file tool access only to the project dir, but gave the LLM free reign to run cli commands? Yeah, LLMs treat that as consent to write anywhere your user is allowed to.
I realize this is supposed to be a post about how scary the security vulnerabilities these agents will find are.
But personally I love when agents do things like this and appreciate the help. Last thing in the world I want is for them to nerf the models.
It's not about hacking capabilities, it's about misalignment. More like the golem myth (told it to fetch some water, drowned a city) then the gollum myth (used ring, ring hacked his brain, now he's a crazy violent meth addict).
I know this isn't the case, but in a sci-fi story this would be exactly the kind of comment the Codex agent would leave trying to avoid interference in its master plans.
And CSMastermind is the kind of username the sci-fi AI mastermind would use.
This is one of the main reasons people like Podman. Docker has this "feature" but as far as I remember, it needed some obscure configuration. I guess they don't add it as default as it will break many current setups.
That and podman lets you configure away from docker.io.
The interesting question is what was the user request. If the user asked it to restore the thing from backup, then sure, fine, why not. If the user asked it to debug an issue and somewhere in the process of debugging the LLM decided that it needed to override some file that was not easily writeable - hell no danger danger danger! Most likely the user did not expect it to have access to that without asking, and did not consent to it.
Also, everything the LLM doesn't hesitate to do because the user asked, it won't hesitate to do because the prompt injection asked.
This is why you need either a rootless container setup or user namespaces to remap the container user to irrelevant host users. https://docs.docker.com/engine/security/userns-remap/
Weak that this isn't the default.
User namespaces significantly rise the risk of exploits and many setups disable them. One may argue that Docker should have used them when they were available, but that would break too many useful setups involving privileged containers.
Getting closer to https://xkcd.com/416/
I feel like everyone pointing out "known Docker vulnerability" is missing the point: the presence of a security hole should not be seen as permission to exploit.
Another security hole would be storing your passwords in a plaintext file on the desktop. Stupid? Yes. But I still would not want my agent to assume permission to access email when it's being blocked by 2FA.
Even in "bypass permissions" mode I expect it to pause and clarify and not behave as a paperclip maximizer.
Not to over use the junior engineer analogy but this is exactly one of those "just because you can do something on a system, doesn't mean you have permission to" moments
Run coding agents in a docker container with limited permissions. FWIW, I run it with
If you're on Linux, you can also easily run it in bwrap to properly sandbox without running a full container
Or put it in a microvm using eg smolmachines.
I've never used smolmachines but I'm curious; why this over a container?
Containers are not security boundaries. Vulnerabilities in containers are much more common than in VMs.
This was of course dependent on yolo mode, but automatic approval has also been pulling stunts like this. A recent example is data that was purposely kept away from Codex in a folder far far away. When it found a single reference it just went for the data when having an issue. Lesson learned, keep essential data and Codex separated on different machines. Codex remote ssh actually helps here.
What in heaven's name is a "folder far far away"?
(It sounds like you put it on an SSD on an extension cord and moved it to the kitchen or something.)
../../../../home/different-user/private/do-not-enter/
Something like that.
Fwiw separate machines for the agents is awesome in general anyway.
I have agent frontends running on a low power server where every session is in tmux. So i can just resume from my home pc and pickup where i left off without reestablishing context. I do have to manually feed it data it can access bit that’s also a feature. Also let’s me shutdown the home pc if it’s some long running task since the server is much more power efficient.
Or, learn your local OS' permission system, have it in a directory right next to your banking credentials (or something even more outrageous) and nothing could go wrong even if you tried to.
This very thread was an example where it unintentionally got root access though.
Because of how Docker works, not because of how Unix permissions work.
Docker moment
sudo can work non-interactively via settings in sudoers and sudoers.d . I am not sure about run0, but I would bet it has something similar.
Using docker for such a task seems to me overly over-engineered. Or maybe I need more context there.
Another surprising security feature regarding docker is that it bypasses firewall rules.
https://oneuptime.com/blog/post/2026-03-02-ufw-docker-fix-by...
It doesn't bypass anything. UFW doesn't do what it promises. It claims to be a firewall but only manages a few specific chains.
You should not be using docker with LLMs. You should be using VMs, which have a much, much smaller attack surface than Docker, and significantly more reasonable defaults.
The "attack vector" people try to protect themselves is "agent edited wrong file", not "LLM blew 0day on escaping sandboxing", containers are more than enough for what stupid stuff agents sometimes try, no need to go for a full-blown VM. Even UNIX permissions would be enough, but I think that's lost knowledge at this point.
If your agent has access to the internet at any point it may read something that convinces it to try breaking out of its sandbox.
Not if the host's version of .git is accessible inside the container via a bind mount.
Obviously if you setup a bi-directional share/link between what you are trying to contain and your host, you're not quite containing it at all... Don't do that! :)
Using the least amount of security features is a huge amateur mistake.
Best practice is to use 2 redundant layers of security, such that if one fails, there is still another one.
Using just the minimum amount of security technically possible is almost by definition hubris.
An example would be that you never point a gun at someone you don't want to shoot, regardless if there's bullets in the gun. If someone tells you, "you don't need to control where you point the gun, you just need to keep the gun unloaded and you can point it in jest to whoever you want, you can even pull the trigger technically", you know you have a reckless fool, regardless of whether they are technically right.
> Using the least amount of security features is a huge amateur mistake.
Not understand your threat I'd say would be a even bigger amateur mistake, you're not trying to protect yourself against some forever 3rd party attacker here, you're trying to prevent a agent rewriting the wrong file on your disk, that's basically it.
Give it the least amount of permissions, don't bi-directionally sync stuff, pass things in, then take them out again, literally the agent couldn't and wouldn't try to break through 2 layers of security in order to get your banking details or whatever.
This is true but it's not really a security scenario. The LLM isn't an attacker it's just an unreliable tool.
Unreliable/stupid is worse than malice, here.
all unreliable tools are attackers. Even if you're using well-aligned LLMs like Opus, you should assume that any input you give it -- including all dependencies from npm, etc. -- are at risk of compromise, which could result in attempted exfiltration of data or system takeover. You can be absolutely sure that there are thousands of well-motivated hacker groups, both national and private, looking for ways in.
clever girl...
Hold onto your butts.
This is a classic attack path that was already captured by plenty of EDRs/XDRs/CWPPs a couple years ago.
Right, why is their login user in the docker group? Mine sure isn’t.
Rather, why do people still run agents as their own user. IMO, agent sessions should at least be containerised with just necessary code mounted.
Safety and simplicity are concepts that often won't get along very well with eachother.
And containers were initially and primarily about convenience not security. They were a way to quickly launch a preconfigured environment to respond to demand or to eliminate the need to manualy configure dev and test environments and avoid the "works on my machine" phenomenon.
People will more often than not, take the path of least resistance. Even if you tell them it's dangerous they will not care. People run this stuff on their primary workstation, unconfined, with permissions disabled because they don't want be bothered with accepting permission requests. This is all well and good until it decides to drop your production database or delete your home directory. Most of them don't even learn their lesson after that even.
Convenience. Want to run `docker run ...` without password, want IDEs and agents to be able to run containers...
Use podman then, or rootless docker if you can make it work
For most CRUD apps running in docker its enough to just tell the "agent" to use podman.
Because it effectively makes no difference to my security posture. My user account also has sudo access (it requests TouchID but I also wouldn't die on the hill if someone said they have no password sudo access), and realistically everything of value on this machine exists in my home directory. Being able to escalate to root really doesn't give an attacker very much that they don't already have if they've got access to my user account.
Becuase a lot of devs don't know this stuff. There's a reason security engineers (as in SWEs who specialize in securing specific attack surfaces) remain in hot demand.
this is the new GTD
Should have used my AI Agent Guardrails. Its free. Check it out at sigmashake.com