Re: [PATCH RFC 0/3] landlock: Add access rights on created files

["Farid Zakaria" <farid.m.zakaria@gmail.com>]

Hi Justin,

Thank you for engaging me on this RFC. Admittedly, I have not followed
the landlock discussions closely. This was an idea I had concocted while
thinking how we can make Nix sandboxing faster.
(I'm also exploring the space with AI - so I'm a landlock newbie but not
a Nix newbie.)

Mickael, et al: I see that sashiko found some legitimate concerns.
I can fix that up in a V2 if we like the general idea and want to
continue exploring it.

On Sat Oct 24, 2026 at 3:03 PM PDT, Justin Suess wrote:
> On Sat, Oct 24, 2026 at 05:43:26PM -0400, Justin Suess wrote:
>> On Sat, Oct 24, 2026 at 01:39:16PM -0700, Farid Zakaria wrote:
>> > This is a proposal for an idea to add support for landlock to work
>> > better with build systems such as Nix where they want to apply
>> > restrictions but the paths may not yet exist.
>> > 
>> > TL;DR;
>> > ========
>> > 
>> > Landlock rules attach to inodes that exist when a ruleset is built.
>> > That makes a directory shared between trusted and sandboxed tasks hard
>> > to confine: the sandbox may create entries there with
>> > LANDLOCK_ACCESS_FS_MAKE_*, but no rule can name those entries ahead of
>> > time, and granting read access on the directory to cover them exposes
>> > every other entry as well. This series adds a rule flag that grants
>> > access rights on the entries a domain creates in a directory, instead
>> > of on the directory.
>> Hi,
>> 
>> I'll chime in since I run nix and have a little bit of familiarity.
>> 
>> Looking at my (admittedly bloated) nix store.
>> 
>> [justin@zenbox ~]$ ls /nix/store | wc -l
>> 259356
>> 
>> That's a lot of inodes. And a nix derivation creates hundreds if not
>> thousands potentially throughout it's build.
>> 
>> My main concern is that rulesets are generally considered
>> immutable after enforcement. This allows for well-defined semantics on
>> inheritence. This from my understanding would mutate the ruleset after
>> it's already enforced, so changes wouldn't be copied to inherited
>> domains automatically.
>
> * nvm on this, it looks like you are adding them to a different
> heirarchy. The point still stands though on the inode pinning, which you
> pointed out.
>
>

On the cost:

only entries created directly in the directory that has
the rule get recorded. For Nix that is /nix/store, so a build records
one entry per output ($out, $dev, ...). Nothing is recorded for
$out/foo or anything else under $out.

Access there is allowed because the path walk at access time reaches
$out and finds it in the recorded set, the same way a rule on a directory
covers what is beneath it. Existing store paths are never recorded, so the
store's size does not matter... right?

A bad actor could still create many entries in the store
(touch /nix/store/junk1 ... junk1000000), and each one stays pinned
until the domain is freed. I can add a per-domain limit on the number
of created entries. Nix only needs as many as the derivation has
outputs ($out, $dev etc..).

>> 
>> My other concern is with the overhead of automatically generating an inserting
>> a rule for every new inode that gets created. It seems like a complex
>> way to tackle this problem.
>> 
>> But beyond that, let's go back to your usecase.
>> 
>> ....
>> 
>> Basically from what I'm seeing you want to grant some access to certain
>> subdirectories (including newly created ones) but exclude others.
>> 
>> Presumably in the nix case, you want to grant /nix/store/{abc,efg,hij} and NOT
>> /nix/store/{xyz}, but still allow /nix/store/{foo} (the derivation
>> output) to be created and written to. This would allow the nix build to only
>> have access to certain inputs, while being able to write to the /nix/store
>> and produce an output. This is a valid usecase that Landlock cannot today
>> accomplish.
>> 
>> There was this NO_INHERIT series I proposed a little while back.
>> [1] It's sort of the inverse of this (removes accesses inherited from
>> parents rather than granting new access) but would accomplish this
>> goal.
>> 
>> With NO_INHERIT, you could grant whatever access rights you want by default on
>> the parent directory, and place NO_INHERIT on any specific entries you
>> don't want to have inherit those rights. 
>>
> It seems like NO_INHERIT too might scale poorly for the usecase. Since then
> you are trading O(store) for O(inputs) so not much better (strictly
> worse).
>
> Thoughts?
>
> Justin

On NO_INHERIT: besides the O(store) cost, other builds keep adding
paths to the store while this one runs. Those new paths have no
NO_INHERIT rule, so they would inherit the store-wide access and be
readable by the build. With the CREATED flag, nothing is readable
unless a rule covers it.

>> So for nix use case, you could grant no_inherit on everything except the
>> inputs you need, then add READ/WRITE/MKDIR etc on /nix/store. The new
>> directories would inherit this by default, while the ones you added
>> NO_INHERIT on would be restricted.
>> 
>> Additionally, you should also examine the mutable domains proposal by
>> Tingmao Wang, which could also facilitate this usecase as well [2] (i.e by
>> dynamically adding and removing rules with some fanotify/inotify glue).
>> 
>> That being said, neither of these two patchsets / proposals are merged,
>> and the playing field is still open on this.
>> 
>> So the problem you are pointing to is legitamate, but the solution still
>> needs to be considered carefully to avoid complexity.
>> 
>> Justin
>> 
>> [1] https://lore.kernel.org/linux-security-module/20260621035223.2651547-1-utilityemal77@gmail.com/
>> [2] https://lore.kernel.org/linux-security-module/cover.1741047969.git.m@maowtm.org/
>> > Motivation
>> > ==========
>> > 
>> > The motivating user is the Nix build sandbox. Every Nix build runs in
>> > its own sandbox, and a build may only read its declared inputs in
>> > /nix/store and must be able to write and read back the outputs it
>> > creates there. Nix enforces this with a private mount namespace: it
>> > creates an empty store directory and bind-mounts each input path into
>> > it, one mount per input. Nix has paid this per-input cost since the
>> > sandbox was introduced [1].
>> >
>> > The cost is paid per build and grows with the size of the input
>> > closure. Nix is moving towards much finer-grained builds (many small
>> > derivations instead of a few large ones), so the number of sandboxes
>> > grows while each build's own work shrinks, and the sandbox setup is
>> > becoming the bottleneck. A typical build has hundreds of inputs; large
>> > ones have thousands.
>> > 
>> > A microbenchmark sets up and tears down a Nix-like sandbox (user,
>> > mount, PID, IPC, UTS and network namespaces, pivot_root into a chroot,
>> > removing the chroot afterwards). It compares one bind mount per input
>> > with a single bind mount of the whole store plus one Landlock rule per
>> > input. Median latency per sandbox, one sandbox at a time, Linux 7.1,
>> > ext4, 16 cores:
>> > 
>> >   inputs   bind mount per input   one bind mount + Landlock   speedup
>> >       10         3.2 ms                    2.3 ms               1.4x
>> >      100        11.6 ms                    2.8 ms               4.1x
>> >     1000        79.3 ms                    6.4 ms              12.4x
>> >     5000       400.1 ms                   24.4 ms              16.4x
>> > 
>> > With Landlock, an input costs an O_PATH open and a landlock_add_rule()
>> > call: there is a single mount, and no mountpoint directory to create
>> > before the build and remove after it (removing the 1000 empty
>> > mountpoints alone took 17 ms).
>> > 
>> > The single bind mount is only sound if the store listing and the
>> > undeclared store paths stay unreadable while the build can still use
>> > its outputs. Without this series, covering the outputs requires a rule
>> > on /nix/store itself, which makes every store path readable again.
>> > 
>> > [1] https://github.com/NixOS/nix/issues/179
>> > 
>> > Series
>> > ======
>> > 
>> > Patch 1 lets an LSM observe inode creation through the
>> > inode_init_security hook when no LSM provides an xattr. Patch 2 adds
>> > the LANDLOCK_ADD_RULE_CREATED flag for path-beneath rules and bumps the
>> > ABI to 13. Patch 3 adds selftests.
>> > 
>> > Testing
>> > =======
>> > 
>> > The series applies to the Landlock next branch (3e271a27c46f) and was
>> > tested on Linux 7.3 with that branch applied.
>> > 
>> > Without patch 2, the five new tests and the ABI version check fail.
>> > 
>> > Open questions
>> > ==============
>> > 
>> > - A created inode stays pinned until the layer's hierarchy is freed, so a
>> >   sandbox that creates many entries in such a directory keeps them all in
>> >   memory. Should this be bounded?
>> > 
>> > - Creation is detected in inode_init_security, so on filesystems that do
>> >   not call security_inode_init_security() created entries get no rights.
>> >   Is there a better hook?
>> > 
>> > - Through overlayfs, created entries get no rights either, because the
>> >   upper inode is created with the mounter's credentials. Should overlayfs
>> >   be handled, e.g. via security_dentry_create_files_as()?
>> > 
>> > - A file renamed or linked in keeps only the rights it had at its source.
>> >   Should it get none instead?
>> > 
>> > ---
>> > Farid Zakaria (3):
>> >       lsm: Call inode_init_security hooks without xattrs
>> >       landlock: Add access rights on created files
>> >       selftests/landlock: Test LANDLOCK_ADD_RULE_CREATED
>> > 
>> >  Documentation/userspace-api/landlock.rst     |  42 +++++
>> >  include/uapi/linux/landlock.h                |  18 +++
>> >  security/landlock/domain.c                   | 182 ++++++++++++++++++++-
>> >  security/landlock/domain.h                   |  28 ++++
>> >  security/landlock/fs.c                       | 176 +++++++++++++++++++--
>> >  security/landlock/object.h                   |   6 +
>> >  security/landlock/ruleset.c                  |   6 +
>> >  security/landlock/ruleset.h                  |  14 ++
>> >  security/landlock/syscalls.c                 |  20 ++-
>> >  security/security.c                          |   9 +-
>> >  tools/testing/selftests/landlock/base_test.c |   2 +-
>> >  tools/testing/selftests/landlock/fs_test.c   | 227 +++++++++++++++++++++++++++
>> >  12 files changed, 703 insertions(+), 27 deletions(-)
>> > ---
>> > base-commit: 3e271a27c46fd591d1011c7de5a644a41e2010f1
>> > change-id: 20261024-landlock-created-rights-9340b00a8c4d
>> > 
>> > Best regards,
>> > --  
>> > Farid Zakaria <farid.m.zakaria@gmail.com>
>> > 
>> >