protection against unprivileged symbolic links?

[maltek]

Hi,

I've been dealing with some privileged code lately that needs to do e.g. chown on paths owned by arbitrary users. There, the most sensible way to deal with symlinks without allowing privesc is to only follow them if the owner of a link and its target match - or if the link is owned by root. (Somewhat like what the kernel does in directories with sticky bits if fs.protected_symlinks is on.)

Do you consider such a protection in scope for this library? (From a quick scan over the code, I couldn't see it already implemented.)

[cyphar]

It isn't implemented, though I'm not definitely not against the idea. Though, one problem is that we cannot (as easily) implement it for the kernel-mode driver because that actually does the resolution in-kernel.

Though, I think there is a question about what threat model we are defending against by implementing it -- symlinks will always be resolved within a given Root, so are we saying that even within a Root we want to stop an administrative process from following links that could be bad if an in-container administrative process followed them?

[maltek]

Yes, that's the threat model I have in mind. Prevent in-container-unprivileged-user from triggering file system changes that could allow it to escalate to in-container-root. (My use-cases aren't actually with containers at all, but I don't think that changes things.)

[cyphar]

For the kernel side, I could try to add a RESOLVE_PRIVILEGED_SYMLINKS to a future version of the openat2 patchset which implements those semantics. But I'd like to get openat2 merged first 😉.