[PunchyHamster]

> The whole experience was a bit jarring. When it knows I use nix, the the thing can easily `nix-shell -p nmap` its way into learning a lot more about my entire network than I am comfortable with. I think I'll edit the Containerfile further to also make Claude Code a user that can't install anything.

Note that putting it in container changes jack shit, if it still has network access, it can scan your network anyway, and it needs access to install language deps and such to "do its work"

It's a security nightmare.

[simoncion]

> Note that putting it in container changes jack shit, if it still has network access, it can scan your network anyway...

That's why VLANs are nice, as is requiring your container system (or VM or whatever) to attach its vNICs to a VLAN-tagged bridge on the host rather than the untagged interface that your trusted software uses. If the only thing that the container can hit on your LAN is your router, and your router refuses to forward traffic from that untrusted VLAN to anywhere other than the internet, then that cuts off another avenue for intelligence gathering.

That all assumes that you can't exploit the container daemon to get root, of course.

[arcanemachiner]

Every goddamn time with this type of dogshit advice.

Perfect is the enemy of good.

Don't just rawdog a coding agent because a perfectly viable solution (containers) takes an hour or two of work to set up.

There's a world of difference between "it can scan your network" and "I just uploaded my private SSH keys to the cloud".

[simoncion]

> Don't just rawdog a coding agent because a perfectly viable solution (containers) takes an hour or two of work to set up.

Setting up a separate unprivileged Linux user account takes all of like a minute. Assuming that the $HOME for your daily-driver account isn't world-readable, [0] that gets you the majority of the isolation that containerization provides and doesn't expose you to any bugs in the containerization management daemon (or the containerization code, itself) that may still be present even after all these years.

These things are usually TUIs or CLIs, so you don't need to bother with giving them xauth access or whatever the Wayland equivalents for that are.

[0] If it is, you might consider fixing that immediately.

[arcanemachiner]

See, I like this. "Create a new user account" is much better advice than "don't use a container".

My problem with the latter advice is that I know for a fact that people will read it, then continue to use absolutely no protection whasoever.

I have also wanted to use a simple file permission system, but I started with a container and I can't be troubled to switch yet.

[simoncion]

> "Create a new user account" is much better advice than "don't use a container".

That wasn't exactly what PunchyHamster was saying. PH was saying that putting an untrusted workload in a container doesn't prevent it from scanning (and attacking) your network... so your IP network security is just as bad when that untrusted workload is containerized as when it's not. Containers/sandboxes can provide filesystem segmentation (except when they don't! [0]), but the way they're typically used, they provide zero network segmentation.

I mention in my comment here [1] that it's useful for whatever isolation mechanism you use (even if it's "just" 'a separate minimally-privileged user') to ensure that programs its spawns are on separate VLANs that your router prevents from talking to anywhere other than the Internet.

[0] <https://github.com/flatpak/flatpak/security/advisories/GHSA-...>

[1] <https://news.ycombinator.com/item?id=47690425>