filepath-securejoin

Agreed. Not a direct answer but this should be interesting: https://github.com/cyphar/filepath-securejoin

Cool educational project! runc - which is the low-component that does the actual container launching in Docker and other runtimes - is mostly written in Go and quite approachable[1], if you're curious what a production-ready container runtime looks like. Namespaces look simple on the surface, but there are plenty of subleties, particularly when using Go: - `runtime.LockOSThread()` has to be called before entering a namespace to pin the goroutine to a specific OS thread. The unshare call affects only the current thread[2][3]. Even then, you have to be careful not to spawn any new goroutines[4]. For this reason, parts of runc are currently written in C (you could technically implement it in pure Go, but the maintainers believe it's easier to reason about the C implementation). - The container runtime has to reexec itself from a copy of itse

> The new syscall implementation would still need a fallback impl. for older kernels after all. Yup, this is why I'm planning on getting a sane API available in <https://github.com/cyphar/filepath-securejoin> which projects can use so that the correct thing is done with both old and new kernels. Right now it has a (slighly) improved version of the code Docker has, but I'm rewriting it. It should be noted that there are lots of examples of interfaces which are incredibly hard to make safe without openat2 -- such as O_CREAT.

The only currently known and exploitable API is with `docker cp`, but FollowSymlinkInScope is used all over the place. Unfortunately, fixing FollowSymlinkInScope requires redesigning the API and then redesigning all the callers so they stop passing around path strings blindly and instead pass around handles (which are O_PATH fds). But, as I mentioned in TFA, the plan is to rework https://github.com/cyphar/filepath-securejoin to have a sane API that detects attacks on older kernels while using the new kernel bits (once merged).