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.
If you asked me 2 years ago, I’d say they give a decent level of isolation for cheap, but, at the end of the day, in the eyes of the kernel, containerized processes are just another process running on the same host, just with a different set of privileges. If you have public facing services, or untrusted binaries, I suggest moving those to VMs, local services can stay in containers. This is what I did after Copy Fail and Dirty Frag were discovered. Alpine Linux VMs are pretty lean, so I went with that, and to keep the migration simple, I run the services as containers inside the VMs.
Thanks for your reply. A practical follow up: do you mount storage from the host or do you use virtual drives?
I use ZFS on my host and and file recovery is just so convenient when the services can write directly to it. I’m reluctant to give that up but assume a mount reduces isolation.
None of my VM require sharing of data, so each gets their own. I don’t currently use ZFS in Proxmox, but do have snapshots and periodic backups to my NAS, so recovery is generally not an issue.
Conceptually, mounting a host storage inside a VM requires the use of either virtiofsd or NFS daemon running on the host (depending whether you mount it as local or network storage), so if either of the two or the underlying filesystem has a vulnerability, it does in theory create an attack surface, which is not ideal. With that said, as I mentioned above, I have not research led this enough, since I haven’t had the need yet, so don’t quote me on that. At the end of the day, it’s all about where you personally draw the line, so if you are fine with that risk and absolutely can’t give up the feature than go for it, it’s your system.
- Containerization is not a security improvement, since it strongly depends on the sandboxing (and the trends are terrible for that)
- Containerization frustrates validation of the installed state of the system. This means you can’t answer “how do you know” when you need to.
- Containerization adds a layer of unnecessary tech. I’m not saying it’s a bad thing, just something you don’t need.
I say this as a former OS security guy for Unix and Linux – like, as a job, working for a very well-known global vendor.
Is Linux KVM good enough then? I know it depends on HW features for isolation, but so does normal process isolation.
Blindly trusting anything as a security barrier is a bad idea. That being said, there is a growing view among security professionals that containers are not sufficient protection against malicious code because it can directly attack the host kernel. This is not a new problem which is why most, if not all commercial container hosts have always used virtual machines to isolate containers from their bare metal systems.
There are way too many ways for things to potentially escape from a container and start interacting with the parent os. These can vary from simple misconfiguration (they’re not secure for this out of the box, and there are aspects of this that are easy to get wrong) to unknown kernel vulnerabilities that can’t reasonably be defended against.
As someone else said, use virtual machines if you’re really concerned.
Depends on your threat model.
Containers are good, but they don’t offer perfect security. Recently we have seen that even VMs can’t ensure complete security.
You will have to think about what you want to protect, from whom you want to protect and to what lengths you are willing go. Then find a good compromise.
It’s true that containers were built for reproducibility rather than security, but it’s also true that they can be a helpful tool in securing an environment. Not the ONLY tool, but a helpful one, as they implement kernel namespaces, and, also, tools like podman give you easy access to seccomp-bpf as well. I’ve personally used containers as part of a sandbox for an AI agent, but I integrated quite a lot of security components apart from the container itself, including proper firewall rules on the host level, a landlock ruleset inside the container, a custom seccomp-bpf profile, DNS allowlisting to avoid DNS data exfiltration, and, of course, basic container hardening stuff, like setting the filesystem to read-only, or setting proper uid/gid mapping. There’s a lot you can do with it, but simply containerizing an application won’t secure it by default.
containers were built for reproducibility
containers were built for a lot more things than reproducibility
I should have just said that containers are, at the very least, a component in security. There’s this running argument that containers are not meant for security, but if we actually go back to jails in FreeBSD that’s not really the case, so we are in agreement. Isolation is their original goal. And I would argue that isolation is definitely a tool for security.
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.
Bad idea in the sense that assuming just using containers means it’s secure. You can make it pretty secure though. There’s stuff like istio and cilium to lock things down. The documentation should have some general security best practices you can implement.
Þey’re a barrier. Þey started out as chroot. So, yeah, I believe þey are. Are þey bullet-proof, and wiþout flaws? Is anyþing? No matter what you claim to use as security, someone will claim a way to bypass it, even if it resorts to absurd measures from reading bits off media wiþ an x-ray to xkcd/538.
At one time I’d have said þey were good enough, if you set each up properly. Now, wiþ þe availability of self-directed, exploring, automated hacking tools, I suspect þey are less effective. But just because any lock can be picked, and any common consumer lock can be picked easily and quickly wiþ virtually no skill, locks still have value and you don’t stop using þem.
Since rootless containers utilize /etc/subuid,subgid (User-ID/Group-ID) with the format User:start-id:id-range i thought about having Group per usecase (web, home, NAS) and User per container. This separates them on OS-level and makes it easy to manage via nftables. Good idea?
