[PATCH v4 1/4] landlock: Fix handling of disconnected directories
Mickaël Salaün
mic at digikod.net
Fri Nov 28 16:56:39 UTC 2025
On Fri, Nov 28, 2025 at 01:45:29AM +0000, Tingmao Wang wrote:
> Hi Mickaël,
>
> I think this implementation makes sense - to me this feels better than
> ignoring rules between the leaf and the mount when disconnected, given the
> interaction with domain checks. This approach is also simpler in code.
>
> However, there is one caveat which, while requiring a slightly problematic
> policy to happen in the first place, might still be a bit surprising: if,
> for some reason, there are rules "hidden" in the "real" parent of a (bind)
> mounted dir, a sandboxed program that is able to cause directories to be
> disconnected (for example, because there are more bind mounts within the
> bind mount, and the program has enough rename access (but not read/write))
> may be able to "surface" those rules and "gain access" (requires the
> existance of the already questionable "hidden" rule):
The crux of the issue is indeed the policy.
>
> root at g3ef6e4434e3a-dirty /# mkdir -p /hidden/bind1_src /bind1_dst
> /# cd hidden
> /hidden# mount --bind bind1_src /bind1_dst
> /hidden# mkdir -p bind1_src/bind2_src/dir bind1_src/bind2_dst
> /hidden# mount --bind /bind1_dst/bind2_src /bind1_dst/bind2_dst
> /hidden# echo secret > bind1_src/bind2_src/dir/secret
> /hidden# ls -la /bind1_dst/bind2_dst/dir/secret
> -rw-r--r-- 1 root root 7 Nov 28 00:49 /bind1_dst/bind2_dst/dir/secret
> /hidden# mount -t tmpfs none /hidden
> /hidden# ls .
> bind1_src/
> /hidden# ls /hidden
> /hidden# LL_FS_RO=/usr:/bin:/lib:/etc:. LL_FS_RW= LL_FS_CREATE_DELETE_REFER=./bind1_src /sandboxer bash
> ^ this attaches a read rule to a "invisible" dir
> Executing the sandboxed command...
> /hidden# cd /
> /# ls /hidden
> ls: cannot open directory '/hidden': Permission denied
> /# cd /bind1_dst/bind2_dst/dir
> /bind1_dst/bind2_dst/dir# cat secret
> cat: secret: Permission denied
> /bind1_dst/bind2_dst/dir# mv -v /bind1_dst/bind2_src/dir /bind1_dst/outside
> renamed '/bind1_dst/bind2_src/dir' -> '/bind1_dst/outside'
> /bind1_dst/bind2_dst/dir# ls ..
> ls: cannot access '..': No such file or directory
> /bind1_dst/bind2_dst/dir# cat secret
> secret
This is valid, but in this case access to secret is explicitly allowed
by the policy, even if the related path is no longer reachable.
>
> Earlier I was thinking we could make domain check for rename/links
> stricter, in that it would make sure there are no rules granting more
> access on the destination than what's granted by the "visible" rules on
> the source even if those rules are "hidden" within the fs above the
> mountpoint. This way, the application would not be able to move the
> source's parent to cause a disconnection in the first place. However, I'm
> not sure if this is worth the complication (e.g. in the case of exchange
> rename, source is also the destination, and so this check needs to also
> check that there are no "hidden" rules on the source that grants more access
> than the "visible" rules on the destination).
>
> I see another approach to mitigate this - we can disallow (return with
> -EXDEV probably) rename/links altogether when the destination (and also
> source if exchange) contains "hidden" rules that grants more access than
> the "visible" rules. However this approach would break backward
> compatibility if a sandboxer or Landlock-enlightened application creates
> such problematic policies (most likely unknowingly).
>
> Stepping back a bit, I also think it is reasonable to leave this issue as
> is and not mitigate it (maybe warn about it in some way in the docs),
> given that this can only happen if the policy is already weird (if the
> intention is to protect some file, setting an allow access rule on its
> parent, even if that parent is "hidden", is questionable).
I agree.
>
> Not sure which is best, but even with this issue this patch is probably
> still an improvement over the existing behavior (i.e. the one currently in
> mainline, where if the path is disconnected, the "hidden" rules are used
> and any "normal" rules from mnt_parent and above are ignored).
>
> Reviewed-by: Tingmao Wang <m at maowtm.org>
Thanks for the deep analysis!
>
> Kind regards,
> Tingmao
>
More information about the Linux-security-module-archive
mailing list