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

[Farid Zakaria]

On Fri Oct 30, 2026 at 5:09 AM PDT, Mickaël Salaün wrote:

Sorry for the late response.
I welcomed a new member to the family (kid #4!), so I've been a little
more busy than usual ;)

> Hi Farid,
>
> Thanks for this RFC.  The Nix build sandbox is definitely a valid use
> case for Landlock.
>
> I didn't have time to do a full review of your patches yet, but I'll do
> that next week.  In the meantime, I have a few questions:
>
>
> 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.
>> 
>> 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
>
> Did you do this benchmark with this series?  Do you have the related
> code to easily reproduce it?
>

I have uploaded the benchmark and steps here:
https://gist.github.com/fzakaria/3c9589f17cb54e6e35165e11402686a2

>> 
>> 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
>
> I'm wondering if the Nix build sandbox can create the store dir per
> build before the actual build.  Isn't already the case with the bind
> mount?
>

The problem is that it's not always a directory; it can be a file or a
symlink. The builder communicates success also via the creation of the
output path as well, so the pre-creation of it would circumvent that.



>> 
>> 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?
>
> Only the sandbox creator should pay for the related kernel memory
> allocations, and this should be at creation time.

That is not the case in this version. The allocation happens in
landlock_add_created().

>
> Another property that would be nice is that if a sandboxed process can
> create a file, the related policy should also make it possible to delete
> this file.  Is that the case with the current approach?  We need to
> think not only about the lifetime of the sandbox, but about consecutive
> creations of such sandboxes by/for the same program.
>

Partially with this implementation. The sandbox can delete all entries
below due to teh hierarchical nature of the rule but cannot delete he
entry.

I will do more research about consecutive sandboxes.

The research I have done so far from the the feedback on this RFC though
leads me to believe Gunther's parent + basename approach.

I guess overall this RFC is to add support for a feature where we can
apply landlock rules to files/directories that are not yet created via
the Nix use case.

>> 
>> - 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@xxxxxxxxx>
>> 
>>