Containers only got so popular as a tool for developers to make developing/deploying easier. If you want to use them as a security layer that is a completely different goal and has many highly dangerous pitfalls [1]. Just last week there was a post where people were shocked how an AI agent used docker to bypass sudo on a system. I'd imagine this could happen to most people who installed docker. So if you want to use containers for anything but easier development, you need to be much more proficient than the average user already. In that case not exposing $HOME is just a small thing on your config to-do list.

[1] https://cheatsheetseries.owasp.org/cheatsheets/Docker_Securi...

▲

lxgr 5 days ago | parent | next [-]

> Just last week there was a post where people were shocked how an AI agent used docker to bypass sudo on a system.

This was due to implicitly granting the LLM access to the host docker daemon, which has superuser privileges, not due to a "container breakout". That's arguably a very different scenario, but of course both are worth considering.

> So if you want to use containers for anything but easier development, you need to be much more proficient than the average user already.

I'd disagree. Containers, at least without granting them additional privileges such as CAP_NET_ADMIN and without write-bind-mounting sensitive host directories into the container, offer a reasonable security boundary compared to the counterfactual, despite their bad reputation.

▲

sigmoid10 5 days ago | parent [-]

>without granting them additional privileges such as CAP_NET_ADMIN and without write-bind-mounting sensitive host directories into the container, offer a reasonable security boundary compared to the counterfactua

There's much more to it than that if you check out the link above. Misconfiguring a container is the 2026 version of misconfiguring FTP and MYSQL in the 90s. I.e. most users don't even know how they are asking to get rooted.

▲

lxgr 5 days ago | parent [-]

If you let your container write setuid binaries to your path, give it admin access to your network, let it access the Docker daemon socket etc., sure, you're going to have a bad time. But how is that different from e.g. giving software running in a VM SSH access to your host or a writable bind mount to the host's root directory?

	▲	fc417fc802 5 days ago \| parent [-]
		Yeah all of that stuff seems reasonably obvious. If you fire up a default unprivileged container with a network adapter but no other affordances it shouldn't have any holes. (If it does those are either runtime or distro bugs.) AFAICT all the security problems are fairly obvious own goals inflicted after that point.

▲

kenanfyi 5 days ago | parent | prev | next [-]

I see. Why this interests me is the similar stuff I have been reading lately. All these supply chain attacks regarding npm, Tanstack etc. Therefore I wanted to create a totally isolated sandbox and while considering options I have seen they all by default mount the $HOME. I needed to explicitly tell colima to not do that.

But yeah, I guess my use case is not the main use of such tools or their purpose in general. Thanks for the link, I‘ll take a look at it.

▲

pojzon 4 days ago | parent | prev [-]

Im currently working on an article about this very topic. And its amazing how hard and multi-dimensional agent sandboxing. LLMs architecture is by design insecure. Working with something like this and making it secure to run in production is extremely interesting topic.