4 ms·
In fact, the authors specifically say on the very first line of their website that the copy/fail primitive can be used as a container escape. The entire premis
by hlieberman 5mo ago
In fact, the authors specifically say on the very first line of their website that the copy/fail primitive can be used as a container escape. The entire premise of this article is flawed and irresponsible.
- deleted 5mo ago[deleted]
- eqvinox 5mo agoAIUI they haven't shown a container escape and are just claiming it so far. Or did I miss something?
- angry_octet 5mo agoIt's not hard to see ways to escape the container with a cache write primative. I suspect the copy.fail team have held back on releasing a POC because of the disruption it could cause.
- eqvinox 5mo agoIt's not a cache write primitive though; it's a write-to-readable-mappings primitive. At least the way I understood it is, you need to be able to get a (read) file descriptor to the target in order to throw it into the splice() syscall. Now, there are some "funky" no-fs things that could be opened and are mmap'able/spliceable (some stuff in /proc/*, no idea what exactly though), but it's not immediately obvious to me how this is a generic container escape.
- mjmas 5mo agoHaving write access on anything you can read should be enough if libraries or binaries are shared (read-only) between the host and container.
- eqvinox 5mo ago> if libraries or binaries are shared (read-only) between the host and container. Yeah, exactly - that's a pretty big "if", and not how a lot of container automation does things. In particular you'd need to hit the base system, it's no help at all if some application files that the host does nothing with can be hit.