Any ideas why this is branded as "Docker"? Are the same namespacing constructs not being used by other Linux container runtimes? I think this should be titled "Escaping Linux containers" as docker is not at fault here?
There's a long tradition by enterprise vendors large and small to market someone else's product as insecure, in order to create demand for their "improved, secured" version.
In this particular instance, Twistlock is selling Docker security by amplifying the meme of "insecure Docker". The Docker brand has visibility the target audience (Enterprise IT) so it's a good target for this kind of piggyback.
This type of FUD marketing happens all the time in many different markets, it's not specific to Docker.
The author shows a concrete exploit of the kernel bug described in CVE-2017-5123 as he has developed it in the context of the docker container environment.
He shows how to use this bug to break out of docker, so he calls the blog post "Escaping Docker ...".
Which is IMHO the most interesting container runtime to write such an exploit for first because it is very widely deployed, but it might also just have been what the author is most familiar with or what was easiest to develop for him.
How would you reasonably talk about "Linux containers" without having a very exhaustive list of all existing implementations and testing all of them? If one of them is not affected you are now factually wrong.
Let's make it realistic and say he had used RedHat OpenShift as his target and example for the exploit. I'd be completely fine with the title referencing that exact product by name.
Why would he have to dance around what he is using in his demo? Maybe that concrete product has multiple layers of security or lacks them, or uses a certain version etc. He can only speak to what he himself was using and testing. "Escaping Docker container..." is the best short description (as you would need it for a title) of this demo exploit I can think of.
But to answer the spirit your question, each container runtime uses its own peculiar combination of such constructs. It's helpful to know that this attack allows you to break out of the combination used specifically by runc, and thereby to break out of any system relying on Docker (with the default runc execution driver.)