Does anyone know if there is a website that hosts the major containers like Docker openly with public shell access to prove security? Perhaps they could be assigned a rating of the number of hours they lasted before someone escaped to host. It seems to me that we need a registry of ONLY containers and images that have stood the test of time.

The page would provide a shell which anyone could use to try to break out of the container. They'd have use of any tools that an exploited container would have, including apt-get and even root access. Ideally all ports would be closed and there would be no host network or volume access. But there could be tiers for each level of communication available.

This would give us one of two outcomes:

1) Secure containers and images would be found.

Or more likely (due to Spectre, Heartbleed, Meltdown, Rowhammer, etc, etc, etc, not to mention the countless kernel exploits and unpublicized hacks):

2) We'd find that there are currently no secure containers or images and we're all living in a fantasy.

My feeling is that #2 will be the outcome, but that there's nothing mathematically insecure about containers. It's just that we've lived under conceptually incorrect paradigms for so long that it's easier to buy into denial than decide to start over and rewrite the bad parts.

I agree strongly with number 2, and characterize it as, “there’s no such thing as a container”.

It clarifies security thinking if you pretend you don’t have a container, but instead, you’ve got a new kind of tar file, some namespacing, some niceness, iptables, and some convenience aliases:

https://github.com/p8952/bocker

None of it’s magic, and none of it brings new security guarantees. There’s just the stuff hosts had, that’s what they still have, so however you secured a process under that stuff, you still must do it to a process under this stuff, just now against an extra pile of abstractions and duplicate OS cruft.

Devs are mad at the security team because they want to inexplicably pile another dubious OS into with apt-getted software of dubious third party libs somehow expecting the whole thing to be safer, and the security team reaction is to want to “scan” the pile of nonsense.

Both groups, and the vendors exploiting them, desperately do not want to grapple with the implications of your point 2.

This position is not popular.

As for point 1, it could be argued Google is continuing this experiment, and learning from it, as seen in more than one CVE last year addresses obtaining root on GKE:

https://cloud.google.com/kubernetes-engine/docs/security-bul...

That said, your point 1 can be found, if you already had a way of securing a public host with security boundaries asserted from outside the host.

For instance, one of the GKE CVEs mentions the GKE Sandbox relying on gVisor:

https://cloud.google.com/kubernetes-engine/docs/concepts/san...

https://gvisor.dev/docs/

(About that extra OS in the container, note Google’s plea for distroless and no shell. Are folks even listening?)