Handling the Kubernetes symbolic link vulnerability
Handling the Kubernetes symbolic link vulnerability
Posted Dec 28, 2018 6:23 UTC (Fri) by cyphar (subscriber, #110703)In reply to: Handling the Kubernetes symbolic link vulnerability by jra
Parent article: Handling the Kubernetes symbolic link vulnerability
> This is why the handle-based approach got retrofitted into POSIX via the XXXat() interfaces to get around the problem with the normal interfaces.
Unfortunately just using *at(2) isn't really sufficient. You would need to do full path lookups (as in at least one openat(2) for each component of your path) in userspace with some pretty ugly checking (fstatat(2) or potentially readlink("/proc/self/fd/$foo")) in order to verify you haven't been thrown out of where you expect.
This is is why I am working on adding O_BENEATH and similar openat(2) flags so the kernel will do the checks for you[1] (since the kernel can actually do checks somewhat-atomically within VFS). Hopefully it'll remove some of these really frustrating hurdles.