In a comment over at !selfhosted@lemmy.world someone wrote:

Containers are not a security barrier. They cannot be, they never will be.

I’m no expert but my mental model of containers was different in that I thought containerized processes live in somehow separate environments, at least filesystem- and network-wise.

I run self-hosted services in containers on my server to isolate them from each other, and now and then binaries I don’t fully trust (things like suspected slop code or not well known python libraries) in containers on my laptop.

Does someone with more technical knowledge about how containers work feel like explaining whether that is a bad idea and if so why? That would be highly appreciated.

Edit: missing words and punctuation.

Edit 2: I would like to thank everyone who took the time to reply. My key take aways are that I will move my self-hosted services into VMs for proper isolation, but that it’s probably fine to use a container when I want to make sure an LLM doesn’t accidentally rm -rf my laptop system when it gets stuck.

  • non_burglar@lemmy.world
    link
    fedilink
    arrow-up
    5
    ·
    1 day ago

    It’s more useful to consider a container an administrative separation, and as others have mentioned here, being vigilant means not trusting any one technology implicitly.

    Cgroups2 and libcontainer do a decent job now of separating child processes from host processes and resources, but with ai-assisted tooling will eventually come the discovery of more vulns and escapes at a more accelerated pace. In those times, when everyone is panicking, having cultivated other good security habits will bring you some measure of understanding what exactly your risks are.

    Containers are somewhat separated from the host os in a functional way, I don’t think your mental model is wrong, per se, but that separation shouldn’t be relied on by itself.