Hacker News Reader

Comment by Ajedi32 | Hacker News Reader

That's why adding your user account to the docker group is a separate step that explicitly does not happen as part of the installation: https://docs.docker.com/engine/install/linux-postinstall/

> Warning

> The docker group grants root-level privileges to the user. For details on how this impacts security in your system, see Docker Daemon Attack Surface.

View on HN

wait so just being lazy and using sudo on Docker commands instead of figuring things out actually means I'm being safer? awesome.

No, because a malicious AI agent could just replace the sudo binary in your path with one that collects your password and uses it to execute arbitrary code as root. Nothing short of sandboxing everything or just never using AI agents or proprietary software will prevent this.

Once I noticed that models will treat lack of superuser access as an obstacle I moved all of the agent crap to its own machine. Watching some mid-tier offering chain together tools like its a gorilla escaping the zoo and I'm just not going to deal with that situation.

I'm more worried about my `~/.aws` and `~/.ssh` folders. People who use IDE-based AI tooling with IDEs that support dev-containers have no excuse for not leveraging dev containers, both for preventing agents losing your data and defending against secrets-harvesting supply-chain attacks

Using containers as a security boundary is inexcusable.

That entirely depends on one's threat-model. Also, containerization is 100x better than rawdogging.

> That entirely depends on one's threat-model

I think not, virtualization has such low overhead now that there's just no excuse. It's generally trivial to switch from containers to VMs.

It is excusable if all you care about is blocking sudo access while letting the ai use a pseudo sudo.

Could you elaborate on this?

The cost-benefit ratio of using VMs over containers is very high. You trade negligible overhead for an actual security boundary.

Containers don't provide good isolation and tend to be trivial to break out of.

It's why all of my agent run in a vm. I refuse to have it run on my own machine. Claude code once managed to render the vm unbootable, I was back in action 5 minutes later after regenerating the vm

What were you trying to tell it to do?

I recently took the risk there by having it run xattr commands to fix some MacOS bug with Tahoe that broke auto update for what seems like all software.

oh I just told it it could install any dependencies it needed. To be fair, the VM runs arch linux and well arch does come with foot guns.

My agent has access to my email, my messages, my work, my finances, my life. But thank god it doesn't have access to root on my machine.

As always. XKCD: https://xkcd.com/1200/

> Nothing short of sandboxing everything or just never using AI agents or proprietary software will prevent this.

Using open-source (non-proprietary) software won’t necessarily save you either. XZ is open-source and it was basically dumb luck that we weren’t all infected. Same with the myriad exploits to NPM.

Ok but in this case the problem wasn't the AI agent - the AI agent merely took advantage of this prior problem in the first place. For instance, if docker group were not superuser-like, that issue could not have happened.

> Nothing short of sandboxing everything or just never using AI agents

But the problem was not the AI agent.

Sandboxing is quite neat though; I remember on GoboLinux the idea of AlienFS to have every application run in a sandboxed manner, so it would only see other programs it needs, but never more than that. I consider it a better engineering focus to have this as minimal layer, even outside of security-related concerns.

If malicious AI has replaced the sudo binary, then it can already run arbitrary code as root. No need to "collect your password" then

It could just alias sudo on your ~/.bashrc. No need to replace the actual file on /usr/bin/sudo or wherever you have it. I would only need to be able to run arbitrary code as you.

Sigh. What ever happened to the principle of least privilege and why arent we applying it to AI agents. They ought to be locked in a box and not capable to act outside designated task.

This feels like using Docker is just inherently unsafe.

The fact that Docker is unsafe was one of the core motivations for Podman.

Was gonna say, "why not podman?"

No, using AI tools not in an effective sandbox is inherently unsafe.

Both can be true.

Yes, that's why they warn you about it.

That’s what rootless docker is for

rootless docker's networking (slirp4netns) is still terribly buggy and in edge cases often locks up using 100% CPU until you discover that your laptop is a lapwarmer and kill it

I found it pretty reliable and use it across all my docker projects, development and production.

This feels like using sudo is just inherently unsafe.

This but unironically. There's no way to ensure that nobody overwrote your .profile or .bashrc with a backdoored sudo that steals your password, or runs your command and then runs an evil command afterwards.

`which sudo`?

`/usr/bin/sudo`?

If they can override sudo, they can override which.

if you use \which it'll always be a shell built-in ;) though someone can put a different shell in your .zshrc

  $ which() { echo foo; }
  $ \which
  foo

The backslash only prevents alias expansion.

He meant `command which`

> it'll always be a shell built-in

`command which` wouldn't have been the built-in

`exec /tmp/fake-bash` in bashrc to intercept everything?

Then use the absolute path.

It is. That's why SELinux and AppArmor were invented.

Instead of having "root" and "user", both of these provide sets of permissions that can be granted to apps.

In this case, SELinux would've stopped this. Codex could've still relabelled the files when mounting but this can be blocked for sensitive directories like /etc.

This feels like using a computer is inherently unsafe.

On the plus side, once we outlaw them we'll shut down the ability for conspiratorial thinking to spread easily and the world will slowly heal from the last couple of decades (the previous one in particular).

Hooray! We're finally doing something about the harms of social media. Smash your computer today!

Safety meeting. Nobody works, nobody gets hurt.

Ah yes, it’s the conspiratorial thinking dividing society,

not humans being humans,

not the people at the highest echelons of society being corrupt (Epstein called).

It’s the people trying to piece that evil together so they know what to tell their kids - they’re the problem.

Sure.

I think we're only a few decades away from these things being said unironically.

It's already here, mobile OSes are just computers with ton of guardrails and you can't do whatever you want with it, for the sake of security. I mean we almost got an Android where you can't install the APK you want.

Where's that guy with the ButlerianJihad username when you need him?

funily less is often more in security while ur devving. but its best to be aware rather than lucky :p

Well in 2026 most likely this step was also done by an agent with --dangerously-skip-permissions

And containers were supposed to make things safer ...

Huge design mistake if you ask me.

i don't see how it's a design mistake, linux allows more footguns in general to not decrease utility. Allowing you to manually give root prompt access (with warnings!) to a non-root user is one of them.

you can also just not run docker as root and not add normal users to the docker group

> And containers were supposed to make things safer ...

No. Containers are a slight improvement over the .tar.gz software distribution method we had a few decades ago.

(And I mean "slight" literally - a Docker container is just a .tar.gz with a bundled bash script that runs in a chroot.)

Containers were never a security boundary

Reply on news.ycombinator.com