Re: Safety of resolving untrusted paths with detached mount dirfd

[Demi Marie Obenour]

On 11/19/25 21:18, Aleksa Sarai wrote:
> On 2025-11-19, Alyssa Ross <hi@xxxxxxxxx> wrote:
>> Hello,
>>
>> As we know, it's not safe to use chroot() for resolving untrusted paths
>> within some root, as a subdirectory could be moved outside of the
>> process root while walking the path[1].  On the other hand,
>> LOOKUP_BENEATH is supposed to be robust against this, and going by [2],
>> it sounds like resolving with the mount namespace root as dirfd should
>> also be.
>>
>> My question is: would resolving an untrusted path against a detached
>> mount root dirfd opened with OPEN_TREE_CLONE (not necessarily a
>> filesystem root) also be expected to be robust against traversal issues?
>> i.e. can I rely on an untrusted path never resolving to a path that
>> isn't under the mount root?
> 
> No, if you hit an absolute symlink or use an absolute path it will
> resolve to your current->fs->root (mount namespace root or chroot).
> However, OPEN_TREE_CLONE will stop ".." from naively stepping out of the
> detached bind-mount. If you are dealing with procfs then magic-links can
> also jump out.

Is using open_tree_attr() with MOUNT_ATTR_NOSYMFOLLOW enough to prevent
these?  Will it still provide protection even if someone concurrently
renames one of the files out from under the root?  I know that can
escape a chroot, but I wonder if this provides more guarantees.
https://github.com/QubesOS/qubes-secpack/blob/main/QSBs/qsb-014-2015.txt
was the chroot breakout.

> You can always use RESOLVE_BENEATH or RESOLVE_IN_ROOT in combination
> with OPEN_TREE_CLONE.
Unfortunately not everything supports that.  For instance, mkdirat()
doesn't.
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)

Attachment: OpenPGP_0xB288B55FFF9C22C1.asc
Description: OpenPGP public key

Attachment: OpenPGP_signature.asc
Description: OpenPGP digital signature