I got annoyed when codex by default running in needing confirmation mode, read my .ssh, because it was debugging some slow render (hosting service) command, the fact that CLI did not stop it or require my permission to not only read anything outside the project (and not accidentally), but this specific location, seems like malice to me. I checked and on defaults it has no problems or preference for asking for any approval regarding reading outside the project dir.
And yes, of course you want to run it in a safe way, and if reading that revealed any secrets that would be on me, it didn't but I still think it's not cool at all.
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 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.
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?"
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.
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.
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.
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.
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 has been a known Docker "feature" since the beginning, nothing new here. This pattern is used to configure host machines by some tools.
I got annoyed when codex by default running in needing confirmation mode, read my .ssh, because it was debugging some slow render (hosting service) command, the fact that CLI did not stop it or require my permission to not only read anything outside the project (and not accidentally), but this specific location, seems like malice to me. I checked and on defaults it has no problems or preference for asking for any approval regarding reading outside the project dir.
And yes, of course you want to run it in a safe way, and if reading that revealed any secrets that would be on me, it didn't but I still think it's not cool at all.
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.
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.
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.
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?"
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 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.
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.)
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.
Run coding agents in a docker container with limited permissions. FWIW, I run it with
Or put it in a microvm using eg smolmachines.
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.
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.
Not if the host's version of .git is accessible inside the container via a bind mount.
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...
For most CRUD apps running in docker its enough to just tell the "agent" to use podman.
Use podman then, or rootless docker if you can make it work
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