Message-ID: <fcl5ay76nlftwcqetzxduwlkesmmoyofctnpca5otqecee3bf4@w6hv3lxcwscq>
Date: Tue, 3 Jun 2025 23:13:25 +0200
From: Jan Kara <jack@...e.cz>
To: Mickaël Salaün <mic@...ikod.net>
Cc: Jan Kara <jack@...e.cz>, Song Liu <song@...nel.org>, 
	Alexei Starovoitov <alexei.starovoitov@...il.com>, Al Viro <viro@...iv.linux.org.uk>, bpf <bpf@...r.kernel.org>, 
	Linux-Fsdevel <linux-fsdevel@...r.kernel.org>, LKML <linux-kernel@...r.kernel.org>, 
	LSM List <linux-security-module@...r.kernel.org>, Kernel Team <kernel-team@...a.com>, 
	Andrii Nakryiko <andrii@...nel.org>, Eduard <eddyz87@...il.com>, Alexei Starovoitov <ast@...nel.org>, 
	Daniel Borkmann <daniel@...earbox.net>, Martin KaFai Lau <martin.lau@...ux.dev>, 
	Christian Brauner <brauner@...nel.org>, KP Singh <kpsingh@...nel.org>, 
	Matt Bobrowski <mattbobrowski@...gle.com>, Amir Goldstein <amir73il@...il.com>, repnop@...gle.com, 
	Jeff Layton <jlayton@...nel.org>, Josef Bacik <josef@...icpanda.com>, 
	Günther Noack <gnoack@...gle.com>, Jann Horn <jannh@...gle.com>
Subject: Re: [PATCH bpf-next 3/4] bpf: Introduce path iterator

On Tue 03-06-25 14:49:09, Mickaël Salaün wrote:
> On Tue, Jun 03, 2025 at 11:46:22AM +0200, Jan Kara wrote:
> > On Fri 30-05-25 16:20:39, Mickaël Salaün wrote:
> > > On Thu, May 29, 2025 at 10:05:59AM -0700, Song Liu wrote:
> > > > On Thu, May 29, 2025 at 9:57 AM Alexei Starovoitov
> > > > <alexei.starovoitov@...il.com> wrote:
> > > > [...]
> > > > > >
> > > > > > How about we describe this as:
> > > > > >
> > > > > > Introduce a path iterator, which safely (no crash) walks a struct path.
> > > > > > Without malicious parallel modifications, the walk is guaranteed to
> > > > > > terminate. The sequence of dentries maybe surprising in presence
> > > > > > of parallel directory or mount tree modifications and the iteration may
> > > > > > not ever finish in face of parallel malicious directory tree manipulations.
> > > > >
> > > > > Hold on. If it's really the case then is the landlock susceptible
> > > > > to this type of attack already ?
> > > > > landlock may infinitely loop in the kernel ?
> > > > 
> > > > I think this only happens if the attacker can modify the mount or
> > > > directory tree as fast as the walk, which is probably impossible
> > > > in reality.
> > > 
> > > Yes, so this is not an infinite loop but an infinite race between the
> > > kernel and a very fast malicious user space process with an infinite
> > > number of available nested writable directories, that would also require
> > > a filesystem (and a kernel) supporting infinite pathname length.
> > 
> > Well, you definitely don't need infinite pathname length. Example:
> > 
> > Have a dir hierarchy like:
> > 
> >   A
> >  / \
> > B   C
> > |
> > D
> > 
> > Start iterating from A/B/D, you climb up to A/B. In parallel atacker does:
> > 
> > mv A/B/ A/C/; mkdir A/B
> > 
> > Now by following parent you get to A/C. In parallel attaker does:
> > 
> > mv A/C/ A/B/; mkdir A/C
> > 
> > And now you are essentially where you've started so this can repeat
> > forever.
> 
> Yes, this is the scenario I had in mind talking about "infinite race"
> (instead of infinite loop).  For this to work it will require the
> filesystem to support an infinite number of nested directories, but I'm
> not sure which FS could be eligible.

Well, most filesystems don't limit depth of a directory hierarchy in any
particular way. The depth is limited only by available disk space.

> Anyway, what would would be the threat model for this infinite race?

These kinds of problems can usually lead to DoS. That's not too serious
problem as local users with write fs access can cause smaller or larger
troubles to the system anyway but it can be rather unpleasant e.g. for
container hosting systems if you can force e.g. container management tools
to spend attacker-controlled time in the kernel just because Landlock or
the eBPF "security solution" ends up crawling path in attacker controlled
part of filesystem.

> > As others wrote this particular timing might be hard enough to hit for it
> > to not be a practical attack but I would not bet much on somebody not being
> > able to invent some variant that works, in particular with BPF iterator.
> 
> There might exist corner cases that could be an issue but would the
> impact be different than with other kinds of path walk?

Well, a standard path lookup is limited by the length of the path (and
symlink recursion limit). Things like common parent lookup during rename
acquire locks to block parallel directory tree modifications so similar
attacks are impossible there. It is only the "walk from some dentry to the
root without holding any locks" pattern that has these kind of unbounded
looping issues.

> What could we do to avoid or limit such issue?

That's a tough question. You can hold rename_lock which blocks all
directory renames. This obviously makes the walk-to-the-root safe against
any "rename" attacks but it is a system wide lock with all the obvious
scalability implications. So I don't think that's really feasible. You
could also limit the number of steps in your pathwalk and return error if
it gets exceeded. I believe that would be a more practical solution.

								Honza
-- 
Jan Kara <jack@...e.com>
SUSE Labs, CR

Powered by blists - more mailing lists