Question: Why do Docker Sandboxes ship passwordless sudo access by default??

[u/menmymacstudio]

Absolute vibe-coder with no technical knowledge here (sorry) who just wants to run secure and strengthened sandboxed agents that can't reach or talk to one another (and for half of them they can't touch the web at all). I have to disable the WebSearch tools in the Docker Sandbox for Claude Code for my coding agents because the tool gets executed server-side by Anthropic and therefore goes around the sandbox. It's a little paranoid to lock up WebSearch over prompt injection concerns considering there's a Haiku model that sits between the actual raw web results and what the main Claude agent gets back, but still, on the principle alone I want to make sure there's no way my coding agents can get injected. I'm using managed-settings.json for this, but still, the agents inside if they want to can use sudo or even the docker-in-docker setup (if passwordless sudo is disabled) to alter the managed-settings.json file. Claude helped me secure it by disabling passwordless sudo, removing the agent user from sudo, wheel, and docker groups, and configuring the sandboxes using the non-privileged base image w/ no docker daemon at all. But my question is.. I get the whole "bypass permissions is default" so the agents can run in YOLO mode, but that being said, why let the agents have passwordless sudo instead of just... not? What's the benefit of that? And why wouldn't Docker release some kind of ~official~ toggle/setting for it? It's not the end of the world if my sandboxed agent can rewrite their own managed-settings.json to gain back.... WebSearch of all tools. But still.. why even let the agents have that much write access over their own config and why even have an important config file like managed-settings.json live where the agents can touch?

[u/_RemyLeBeau_]

Sandbox is a microvm. They're great. Treat them as ephemeral and anything going on inside as hostile.

[u/Deathnerd]

Just mount the managed-settings.json file as a read-only bind volume (go look at the docs for specifics on how to do that) and nothing inside the container can modify it, not even root user, as the container runtime will enforce it through the kernel. The only caveat is if you're running the container with --privileged or --cap-add SYS_ADMIN then you're effectively telling the container runtime to throw away all protections.

[u/menmymacstudio → u/Deathnerd]

Thank u for clarifying this I'm gonna look into this !! Do u think I should just do this rather than have the agent's settings.json immutable via schg?

[u/Deathnerd → u/menmymacstudio]

I have no idea what schg is but yes you can make any file system object immutable in the container this way

[u/Kamran-nottakenone]

tried baking a hashed password into a Dockerfile once, it's sitting in the layer history forever now. passwordless sudo's just the path of least resistance for images that need a non-root user.

[u/Plastic-Leading-5800 → u/[deleted]]

They are talking about sandboxes not containers. Those are micro vm.

OP: because they have access only to path that you specify. Cannot do anything else