upvote
> Docker itself is privileged and now any unsandboxed program on your computer can trivially escalate to root.

Inside the sandbox but not on my machine. Show me how it can access an unmounted directory.

> Have you solved for publishing? You'll need your token to enter the container or you'll need an authorizing proxy.

Amazing-sandbox does not solve for that. The current risk is contamination; if you are running `trivy`, it should not need access to tokens in a different env/directory.

> All of these problems and many more go away if the project is built around them from the start.

Please elaborate on your approach that will all me to run markdown/JS/Python/Go/Rust linters and security scanners. Remember that `trivy` which caused `litellm` compromise is a security scanner itself.

> developers can write sandboxes for their software more effectively because they can architect around the sandbox,

Yeah, let's ask 100+ linter providers to write sandboxes for you. I can't even get maintainers to respond to legitimate & trivial PRs many a time.

reply
> Inside the sandbox but not on my machine. Show me how it can access an unmounted directory.

So it says right on the tin of my favorite distro: 'Warning: Beware that the docker group membership is effectively equivalent to being root! Consider using rootless mode below.' So # docker run super-evil-oci-container with a bind mount or two and your would-be attacker doesn't need to guess your sudo password.

reply
> docker run super-evil-oci-container

  1. That super evil OCI container still needs to find a vulnerability in Docker
  2. You can run Docker in rootless mode e.g. Orbstack runs without root
reply
They're suggesting that the attacker is in a position to `docker run`. Any attacker in that position has privesc to root, trivially.

Rootless mode requires unprivileged user namespaces, disabled on almost any distribution because it's a huge security hole in and of itself.

reply
What's particularly vexing is that there is this agentic sandboxing software called "container-use" and out of the box it requires you to add a user to the docker group because they haven't thought about what that really means and why running docker in that configuration option shouldn't be allowed, but instead they have made it mandatory as a default.
reply
I'm not going to code review your sandbox project for you.
reply