linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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
> 

  reply	other threads:[~2025-11-28 16:57 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).