From: "Mickaël Salaün" <mic@digikod.net>
To: Tingmao Wang <m@maowtm.org>
Cc: "Günther Noack" <gnoack@google.com>,
"Al Viro" <viro@zeniv.linux.org.uk>,
"Ben Scarlato" <akhna@google.com>,
"Christian Brauner" <brauner@kernel.org>,
"Jann Horn" <jannh@google.com>, "Jeff Xu" <jeffxu@google.com>,
"Justin Suess" <utilityemal77@gmail.com>,
"Mikhail Ivanov" <ivanov.mikhail1@huawei-partners.com>,
"Paul Moore" <paul@paul-moore.com>, "Song Liu" <song@kernel.org>,
linux-fsdevel@vger.kernel.org,
linux-security-module@vger.kernel.org
Subject: Re: [PATCH v4 1/4] landlock: Fix handling of disconnected directories
Date: Fri, 28 Nov 2025 17:56:39 +0100 [thread overview]
Message-ID: <20251128.oht7Aic8nu9d@digikod.net> (raw)
In-Reply-To: <adf1f57c-8f8e-45a9-922c-4e08899bf14a@maowtm.org>
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@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@maowtm.org>
Thanks for the deep analysis!
>
> Kind regards,
> Tingmao
>
next prev parent reply other threads:[~2025-11-28 17:02 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-26 19:11 [PATCH v4 0/4] Landlock: Disconnected directory handling Mickaël Salaün
2025-11-26 19:11 ` [PATCH v4 1/4] landlock: Fix handling of disconnected directories Mickaël Salaün
2025-11-28 1:45 ` Tingmao Wang
2025-11-28 16:56 ` Mickaël Salaün [this message]
2025-11-28 17:24 ` Tingmao Wang
2025-11-26 19:11 ` [PATCH v4 2/4] landlock: Improve variable scope Mickaël Salaün
2025-11-26 19:11 ` [PATCH v4 3/4] selftests/landlock: Add tests for access through disconnected paths Mickaël Salaün
2025-11-26 19:11 ` [PATCH v4 4/4] selftests/landlock: Add disconnected leafs and branch test suites Mickaël Salaün
2025-11-27 16:49 ` Mickaël Salaün
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20251128.oht7Aic8nu9d@digikod.net \
--to=mic@digikod.net \
--cc=akhna@google.com \
--cc=brauner@kernel.org \
--cc=gnoack@google.com \
--cc=ivanov.mikhail1@huawei-partners.com \
--cc=jannh@google.com \
--cc=jeffxu@google.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=m@maowtm.org \
--cc=paul@paul-moore.com \
--cc=song@kernel.org \
--cc=utilityemal77@gmail.com \
--cc=viro@zeniv.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).