> Containers and namespaces are not about security
People keep saying that, but I do not get it. If an attack that would work without a container, fails from inside a container (e.g. because it cannot read or write a particular file, or it cannot) it is better security.
> A bypassable security mechanism is worse than useless.
It needs the bypass to exist, and it needs an extra step to actually bypass it.
Any security mechanism (short of air gaps) might have a bypass.
> even if a malicious program is still able to detect it's not the true root.
Also true for security unless it can read or write to the true root.
You can use containers as a security measure, but I'd argue that if (when) it fails in a spectacular way (see e. g. abstract sockets for an interesting past issue) it's your fault and not a zero-day in the kernel as a sibling comment suggest. To put it a bit less harsh - containers are not just for security and containerization tools have to balance security vs usability.
I use containers as an extra security measure. i.e. as a way of reducing the chance that a compromise of one process will lead to a compromise of the rest of the system.
That said, I would guess that providers of container hosting must be fairly confident that they can keep them secure. I do not know what extra precautions they take though.
People keep saying that, but I do not get it. If an attack that would work without a container, fails from inside a container (e.g. because it cannot read or write a particular file, or it cannot) it is better security.
> A bypassable security mechanism is worse than useless.
It needs the bypass to exist, and it needs an extra step to actually bypass it.
Any security mechanism (short of air gaps) might have a bypass.
> even if a malicious program is still able to detect it's not the true root.
Also true for security unless it can read or write to the true root.