3 ms·
Given that's the case, I'm sure you can go capture the flag at https://contained.af/ https://contained.af/ .. no one has yet (docker containers, heavy seccomp f
by TheDong 9y ago
Given that's the case, I'm sure you can go capture the flag at https://contained.af/ https://contained.af/ .. no one has yet (docker containers, heavy seccomp filtering).
Or maybe you can break out of the Google App Engine linux container and let me know how it looks (linux containers, quite well-worn at this point)?
Or perhaps you can check for me whether AWS Lambda actually collocates tenents or not (unknown linux containers)?
Or you can launch a heroku dyno and break into another dyno and steal some keys (lxc linux containers)?
In reality, many services do colocate multiple different users together in linux containers. If you use seccomp and ensure the user is unprivileged in the container, it's fairly safe.
Heroku has been doing it for years upon years now.
The other services I named above likely do.
Linux containers absolutely are intended as security boundaries. Kernel bugs which allow escaping a properly setup mount namespace or peeking out of a pid namespace or going from root in a userns to root on the host are all treated as vulnerabilities and patched.
That clearly expresses the intent.
Yes, I agree that in reality they're likely not yet as mature / secure as jails or zones, but I think it's disingenuous to say that Linux containers aren't meant to be security boundaries.
- ungamed 9y ago> . Kernel bugs which allow escaping a properly setup mount namespace or peeking out of a pid namespace or going from root in a userns to root on the host are all treated as vulnerabilities and patched. That clearly expresses the intent. This is because these vulns can be exploited locally without containers.