Question about using Landlock

Question about using Landlock

[Marek Küthe]

[-- Attachment #1: Type: text/plain, Size: 3232 bytes --]

Hello,

I would like to use Landlock in my program to improve security under
Linux. I have a few questions about this:

1. The documentation uses the Landlock functions without syscall. [1]
For example, `landlock_create_ruleset` instead of `int
syscall(SYS_landlock_create_ruleset, ...)`. In which header file are
these landlock_* functions declared? My compiler says it cannot find
them. As a workaround, I currently check whether these functions exist
when configuring the project [2], and if not, I create them [3].
However, this workaround also has problems: syscall returns a long and
the Landlock functions return int, which means I have to perform a
conversion, but there is a possible loss of information from long to
int.

2. I don't quite understand how to add rules to Lockland's rule set.
When accessing the file system, I'm supposed to specify the fd of the
file, but then I already have that file open. And that's exactly what
Lockland is supposed to control. Another problem is that I work with
several libraries: for example, `yaml-cpp` to read my configuration
file, `libtuntap` to create a TAP device, and boost.asio to read and
write from this TAP device. These libraries create files without me
controlling this with my own syscall. How could I integrate Lockland
there?

For example, I create the TAP device (before Lockland controls it) and
then try to restrict access with Lockland. [4] However, I am unsure
whether I am using Lockland correctly.
```
tun_tap dev(config.get_device_name(), tun_tap_mode::tap);
[...]
landlock_ruleset_loop.add_path_beneath_rule(LANDLOCK_ACCESS_FS_WRITE_FILE
| LANDLOCK_ACCESS_FS_READ_FILE | LANDLOCK_ACCESS_FS_IOCTL_DEV,
dev.native_handler());
landlock_ruleset_loop.restrict_self();
[...]
const Crazytrace ct(io.get_executor(), ::dup(dev.native_handler()),
nodecontainer);
io.run();
```

3. Lockland introduces scoped access control starting with ABI 6. To
avoid getting warnings from the compiler (and linter), I need to know
whether the struct landlock_ruleset_attr has scoped access control or
not when programming. Since I only want to support the case where this
is true, I would like to check the ABI version at compile time and
generate a more meaningful error. How can I check the ABI version at
compile time? Is there a macro for this?
Currently, I am using a check to see if the compiler can compile the
struct with `scoped`. [5] However, I don't think this is very elegant.

I hope it's okay for me, as a landlocked newbie, to ask questions like
this here. In any case, I would really appreciate any answers!

Best regards,
Marek Küthe

[1] https://docs.kernel.org/userspace-api/landlock.html
[2]
https://codeberg.org/mark22k/crazytrace/src/commit/c9b3a0e51fadece1228f1f92522dccf0115df84d/meson.build#L101
[3]
https://codeberg.org/mark22k/crazytrace/src/commit/c9b3a0e51fadece1228f1f92522dccf0115df84d/src/landlock.hpp#L14
[4]
https://codeberg.org/mark22k/crazytrace/src/commit/c9b3a0e51fadece1228f1f92522dccf0115df84d/src/main.cpp#L163
[5]
https://codeberg.org/mark22k/crazytrace/src/commit/2580137d0d57b7261bd0e22e11853e9e75c2c2a7/meson.build#L122

-- 
Marek Küthe
m.k@mk16.de
er/ihm he/him

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Question about using Landlock

[Marek Küthe]

[-- Attachment #1: Type: text/plain, Size: 3232 bytes --]

Hello,

I would like to use Landlock in my program to improve security under
Linux. I have a few questions about this:

1. The documentation uses the Landlock functions without syscall. [1]
For example, `landlock_create_ruleset` instead of `int
syscall(SYS_landlock_create_ruleset, ...)`. In which header file are
these landlock_* functions declared? My compiler says it cannot find
them. As a workaround, I currently check whether these functions exist
when configuring the project [2], and if not, I create them [3].
However, this workaround also has problems: syscall returns a long and
the Landlock functions return int, which means I have to perform a
conversion, but there is a possible loss of information from long to
int.

2. I don't quite understand how to add rules to Lockland's rule set.
When accessing the file system, I'm supposed to specify the fd of the
file, but then I already have that file open. And that's exactly what
Lockland is supposed to control. Another problem is that I work with
several libraries: for example, `yaml-cpp` to read my configuration
file, `libtuntap` to create a TAP device, and boost.asio to read and
write from this TAP device. These libraries create files without me
controlling this with my own syscall. How could I integrate Lockland
there?

For example, I create the TAP device (before Lockland controls it) and
then try to restrict access with Lockland. [4] However, I am unsure
whether I am using Lockland correctly.
```
tun_tap dev(config.get_device_name(), tun_tap_mode::tap);
[...]
landlock_ruleset_loop.add_path_beneath_rule(LANDLOCK_ACCESS_FS_WRITE_FILE
| LANDLOCK_ACCESS_FS_READ_FILE | LANDLOCK_ACCESS_FS_IOCTL_DEV,
dev.native_handler());
landlock_ruleset_loop.restrict_self();
[...]
const Crazytrace ct(io.get_executor(), ::dup(dev.native_handler()),
nodecontainer);
io.run();
```

3. Lockland introduces scoped access control starting with ABI 6. To
avoid getting warnings from the compiler (and linter), I need to know
whether the struct landlock_ruleset_attr has scoped access control or
not when programming. Since I only want to support the case where this
is true, I would like to check the ABI version at compile time and
generate a more meaningful error. How can I check the ABI version at
compile time? Is there a macro for this?
Currently, I am using a check to see if the compiler can compile the
struct with `scoped`. [5] However, I don't think this is very elegant.

I hope it's okay for me, as a landlocked newbie, to ask questions like
this here. In any case, I would really appreciate any answers!

Best regards,
Marek Küthe

[1] https://docs.kernel.org/userspace-api/landlock.html
[2]
https://codeberg.org/mark22k/crazytrace/src/commit/c9b3a0e51fadece1228f1f92522dccf0115df84d/meson.build#L101
[3]
https://codeberg.org/mark22k/crazytrace/src/commit/c9b3a0e51fadece1228f1f92522dccf0115df84d/src/landlock.hpp#L14
[4]
https://codeberg.org/mark22k/crazytrace/src/commit/c9b3a0e51fadece1228f1f92522dccf0115df84d/src/main.cpp#L163
[5]
https://codeberg.org/mark22k/crazytrace/src/commit/2580137d0d57b7261bd0e22e11853e9e75c2c2a7/meson.build#L122

-- 
Marek Küthe
m.k@mk16.de
er/ihm he/him

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Question about using Landlock

[Mickaël Salaün]

On Wed, Nov 19, 2025 at 09:19:37PM +0000, Marek Küthe wrote:
> Hello,

Hi!

> 
> I would like to use Landlock in my program to improve security under
> Linux. I have a few questions about this:
> 
> 1. The documentation uses the Landlock functions without syscall. [1]
> For example, `landlock_create_ruleset` instead of `int
> syscall(SYS_landlock_create_ruleset, ...)`. In which header file are
> these landlock_* functions declared? My compiler says it cannot find
> them. As a workaround, I currently check whether these functions exist
> when configuring the project [2], and if not, I create them [3].

There is no glibc wrappers for the Landlock syscalls.  However, we have
some plan to make them available along with some useful helpers, see
https://github.com/landlock-lsm/linux/issues/38

In the meantime, your approach looks good.

> However, this workaround also has problems: syscall returns a long and
> the Landlock functions return int, which means I have to perform a
> conversion, but there is a possible loss of information from long to
> int.

Syscalls on 64-bit architectures indeed return a 64-bit value, but for
syscalls to be compatible with 32-bit architectures, they should not
return values that cannot be represented by a 32-bit value (except
arch-specific types such as pointer or size).  It should be safe to
translate the returned values of Landlock syscalls to int.

FYI, the reference example is here:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/samples/landlock/sandboxer.c

> 
> 2. I don't quite understand how to add rules to Lockland's rule set.

I don't know about Lockland but I'll help you with Landlock. ;)

> When accessing the file system, I'm supposed to specify the fd of the
> file, but then I already have that file open. And that's exactly what
> Lockland is supposed to control.

The goal of a file descriptor is to identify a file or another kernel
resource, without race condition, and in an absolute way.  It doesn't
mean it gives access to the underlying resource (but that's the case
most of the time).  With Landlock, it is encouraged to open files with
O_PATH (see the sandboxer.c example) to avoid leaking opened
files/access.

Using file paths for kernel interfaces should be avoided.

> Another problem is that I work with
> several libraries: for example, `yaml-cpp` to read my configuration
> file, `libtuntap` to create a TAP device, and boost.asio to read and
> write from this TAP device. These libraries create files without me
> controlling this with my own syscall. How could I integrate Lockland
> there?

If they create temporary files, they should do so in $TMPDIR, which you
control.  I guess other file creations should also be controlled by the
developer.

> 
> For example, I create the TAP device (before Lockland controls it) and
> then try to restrict access with Lockland. [4] However, I am unsure
> whether I am using Lockland correctly.
> ```
> tun_tap dev(config.get_device_name(), tun_tap_mode::tap);
> [...]
> landlock_ruleset_loop.add_path_beneath_rule(LANDLOCK_ACCESS_FS_WRITE_FILE
> | LANDLOCK_ACCESS_FS_READ_FILE | LANDLOCK_ACCESS_FS_IOCTL_DEV,
> dev.native_handler());
> landlock_ruleset_loop.restrict_self();
> [...]
> const Crazytrace ct(io.get_executor(), ::dup(dev.native_handler()),
> nodecontainer);
> io.run();
> ```

Creating files before sandboxing itself can make sense wrt to the threat
model (i.e. if the potential attacker cannot interact with the process
at this time).  However, you should try to open the tap device before
the sandboxing and keep the related file descriptor open.  This way you
don't need to bother with the file path of the tap device and you avoid
other potential issues.

> 
> 3. Lockland introduces scoped access control starting with ABI 6. To
> avoid getting warnings from the compiler (and linter), I need to know
> whether the struct landlock_ruleset_attr has scoped access control or
> not when programming. Since I only want to support the case where this
> is true, I would like to check the ABI version at compile time and
> generate a more meaningful error. How can I check the ABI version at
> compile time? Is there a macro for this?

Checking the ABI version at build time is not recommended because it
doesn't give any guarantee about the ABI version at run time.  That's
why the ABI should be a dynamic check.

Another thing to keep in mind is to try to enforce a best-effort
security, exactly for this reason.  We want to protect users as much as
possible, whatever kernel they are using.  However, if a specific
Landlock feature is really required for the program to correctly work,
then we might want to print an error message and exit, but this case
should be very very rare.

> Currently, I am using a check to see if the compiler can compile the
> struct with `scoped`. [5] However, I don't think this is very elegant.

If the scoped field is defined, then you should use it and update it at
runtime according to the current Landlock ABI.  See the sandboxer.c
example for such case.

> 
> I hope it's okay for me, as a landlocked newbie, to ask questions like
> this here. In any case, I would really appreciate any answers!

That's definitely the goal of this mailing list. :)

Please keep us updated about new sandboxed programs.

Regards,
 Mickaël

> 
> Best regards,
> Marek Küthe
> 
> [1] https://docs.kernel.org/userspace-api/landlock.html
> [2]
> https://codeberg.org/mark22k/crazytrace/src/commit/c9b3a0e51fadece1228f1f92522dccf0115df84d/meson.build#L101
> [3]
> https://codeberg.org/mark22k/crazytrace/src/commit/c9b3a0e51fadece1228f1f92522dccf0115df84d/src/landlock.hpp#L14
> [4]
> https://codeberg.org/mark22k/crazytrace/src/commit/c9b3a0e51fadece1228f1f92522dccf0115df84d/src/main.cpp#L163
> [5]
> https://codeberg.org/mark22k/crazytrace/src/commit/2580137d0d57b7261bd0e22e11853e9e75c2c2a7/meson.build#L122
> 
> -- 
> Marek Küthe
> m.k@mk16.de
> er/ihm he/him

Re: Question about using Landlock

[Marek Küthe]

[-- Attachment #1: Type: text/plain, Size: 3205 bytes --]

On Thu, 20 Nov 2025 18:36:50 +0100
Mickaël Salaün <mic@digikod.net> wrote:

> On Wed, Nov 19, 2025 at 09:19:37PM +0000, Marek Küthe wrote:
> > Hello,  
> 
> Hi!

Thanks for your answers! That answered many of my questions.

> > When accessing the file system, I'm supposed to specify the fd of the
> > file, but then I already have that file open. And that's exactly what
> > Lockland is supposed to control.  
> 
> The goal of a file descriptor is to identify a file or another kernel
> resource, without race condition, and in an absolute way.  It doesn't
> mean it gives access to the underlying resource (but that's the case
> most of the time).  With Landlock, it is encouraged to open files with
> O_PATH (see the sandboxer.c example) to avoid leaking opened
> files/access.
> 
> Using file paths for kernel interfaces should be avoided.

Could you give an example? I think you mean fd's that don't refer to
anything in the file system?

> Creating files before sandboxing itself can make sense wrt to the threat
> model (i.e. if the potential attacker cannot interact with the process
> at this time).  However, you should try to open the tap device before
> the sandboxing and keep the related file descriptor open.  This way you
> don't need to bother with the file path of the tap device and you avoid
> other potential issues.

Thanks for the clarification. I'm new to developing "secure programs"
and still need to learn how to create (useful) threat models.

> > 3. Lockland introduces scoped access control starting with ABI 6. To
> > avoid getting warnings from the compiler (and linter), I need to know
> > whether the struct landlock_ruleset_attr has scoped access control or
> > not when programming. Since I only want to support the case where this
> > is true, I would like to check the ABI version at compile time and
> > generate a more meaningful error. How can I check the ABI version at
> > compile time? Is there a macro for this?  
> 
> Checking the ABI version at build time is not recommended because it
> doesn't give any guarantee about the ABI version at run time.  That's
> why the ABI should be a dynamic check.

But I would like to have a build-time guarantee that certain data
structures are available in a certain form or that certain macros
exist. Hence my question about build-time checking.

> > Currently, I am using a check to see if the compiler can compile the
> > struct with `scoped`. [5] However, I don't think this is very elegant.  
> 
> If the scoped field is defined, then you should use it and update it at
> runtime according to the current Landlock ABI.  See the sandboxer.c
> example for such case.

But that assumes that the field exists at build time, and that's
exactly what I want to check.

If I try to initialize a non-existent field, there should be an error
from the compiler (so I want to catch that beforehand). And if I don't
initialize an existing field, clang-tidy complains.

As far as I can tell, sandboxer.c always assumes at build time that it
has been compiled with a new version. Or am I overlooking something?

-- 
Marek Küthe
m.k@mk16.de
er/ihm he/him

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Question about using Landlock

[Mickaël Salaün]

On Thu, Nov 20, 2025 at 08:37:45PM +0000, Marek Küthe wrote:
> On Thu, 20 Nov 2025 18:36:50 +0100
> Mickaël Salaün <mic@digikod.net> wrote:
> 
> > On Wed, Nov 19, 2025 at 09:19:37PM +0000, Marek Küthe wrote:
> > > Hello,  
> > 
> > Hi!
> 
> Thanks for your answers! That answered many of my questions.
> 
> > > When accessing the file system, I'm supposed to specify the fd of the
> > > file, but then I already have that file open. And that's exactly what
> > > Lockland is supposed to control.  
> > 
> > The goal of a file descriptor is to identify a file or another kernel
> > resource, without race condition, and in an absolute way.  It doesn't
> > mean it gives access to the underlying resource (but that's the case
> > most of the time).  With Landlock, it is encouraged to open files with
> > O_PATH (see the sandboxer.c example) to avoid leaking opened
> > files/access.
> > 
> > Using file paths for kernel interfaces should be avoided.
> 
> Could you give an example? I think you mean fd's that don't refer to
> anything in the file system?

I mean that dealing with file paths is racy, it's much better to open a
file once and then perform operations on the related file descriptor
instead of on the same path.  For instance, you can do a lot of things
with syscalls ending with "at" (e.g. openat2 + AT_EMPTY_PATH, ioctl,
read).

> 
> > Creating files before sandboxing itself can make sense wrt to the threat
> > model (i.e. if the potential attacker cannot interact with the process
> > at this time).  However, you should try to open the tap device before
> > the sandboxing and keep the related file descriptor open.  This way you
> > don't need to bother with the file path of the tap device and you avoid
> > other potential issues.
> 
> Thanks for the clarification. I'm new to developing "secure programs"
> and still need to learn how to create (useful) threat models.
> 
> > > 3. Lockland introduces scoped access control starting with ABI 6. To
> > > avoid getting warnings from the compiler (and linter), I need to know
> > > whether the struct landlock_ruleset_attr has scoped access control or
> > > not when programming. Since I only want to support the case where this
> > > is true, I would like to check the ABI version at compile time and
> > > generate a more meaningful error. How can I check the ABI version at
> > > compile time? Is there a macro for this?  
> > 
> > Checking the ABI version at build time is not recommended because it
> > doesn't give any guarantee about the ABI version at run time.  That's
> > why the ABI should be a dynamic check.
> 
> But I would like to have a build-time guarantee that certain data
> structures are available in a certain form or that certain macros
> exist. Hence my question about build-time checking.

You can check the size of a struct at build time, and then infer which
fields are part of it.  We should probably add some helpers to make this
simpler.

It's OK to just copy the header file though.  You'll need to update the
code to leverage new features anyway.

> 
> > > Currently, I am using a check to see if the compiler can compile the
> > > struct with `scoped`. [5] However, I don't think this is very elegant.  
> > 
> > If the scoped field is defined, then you should use it and update it at
> > runtime according to the current Landlock ABI.  See the sandboxer.c
> > example for such case.
> 
> But that assumes that the field exists at build time, and that's
> exactly what I want to check.

sizeof() should help.

> 
> If I try to initialize a non-existent field, there should be an error
> from the compiler (so I want to catch that beforehand). And if I don't
> initialize an existing field, clang-tidy complains.

You should always initialize the Landlock structs to zero, otherwise
you'll get undefined behavior (depending on the content of the stack).
We can initialize a whole struct with empty curly braces e.g.:

  struct landlock_ruleset_attr ruleset_attr = {};

> 
> As far as I can tell, sandboxer.c always assumes at build time that it
> has been compiled with a new version. Or am I overlooking something?

That's correct, and it's the case because the landlock.h file is always
provided with this example, part of the Linux repository.

> 
> -- 
> Marek Küthe
> m.k@mk16.de
> er/ihm he/him

Re: Question about using Landlock

[Jeffrey Walton]

On Fri, Nov 21, 2025 at 9:44 AM Mickaël Salaün <mic@digikod.net> wrote:
>
> On Thu, Nov 20, 2025 at 08:37:45PM +0000, Marek Küthe wrote:
> > On Thu, 20 Nov 2025 18:36:50 +0100
> > Mickaël Salaün <mic@digikod.net> wrote:
> >
> > > On Wed, Nov 19, 2025 at 09:19:37PM +0000, Marek Küthe wrote:
> >
> > Thanks for your answers! That answered many of my questions.
> >
> > > > When accessing the file system, I'm supposed to specify the fd of the
> > > > file, but then I already have that file open. And that's exactly what
> > > > Lockland is supposed to control.
> > >
> > > The goal of a file descriptor is to identify a file or another kernel
> > > resource, without race condition, and in an absolute way.  It doesn't
> > > mean it gives access to the underlying resource (but that's the case
> > > most of the time).  With Landlock, it is encouraged to open files with
> > > O_PATH (see the sandboxer.c example) to avoid leaking opened
> > > files/access.
> > >
> > > Using file paths for kernel interfaces should be avoided.
> >
> > Could you give an example? I think you mean fd's that don't refer to
> > anything in the file system?
>
> I mean that dealing with file paths is racy, it's much better to open a
> file once and then perform operations on the related file descriptor
> instead of on the same path.  For instance, you can do a lot of things
> with syscalls ending with "at" (e.g. openat2 + AT_EMPTY_PATH, ioctl,
> read).

For the OP.... A second benefit of the various *at() functions is a
per-thread working directory in a multithreaded app.  Also see the
Notes section in the openat(2) man page;
<https://linux.die.net/man/2/openat>.

> > > Creating files before sandboxing itself can make sense wrt to the threat
> > > model (i.e. if the potential attacker cannot interact with the process
> > > at this time).  However, you should try to open the tap device before
> > > the sandboxing and keep the related file descriptor open.  This way you
> > > don't need to bother with the file path of the tap device and you avoid
> > > other potential issues.
> >
> > Thanks for the clarification. I'm new to developing "secure programs"
> > and still need to learn how to create (useful) threat models.
> >
> > > > 3. Lockland introduces scoped access control starting with ABI 6. To
> > > > avoid getting warnings from the compiler (and linter), I need to know
> > > > whether the struct landlock_ruleset_attr has scoped access control or
> > > > not when programming. Since I only want to support the case where this
> > > > is true, I would like to check the ABI version at compile time and
> > > > generate a more meaningful error. How can I check the ABI version at
> > > > compile time? Is there a macro for this?
> > >
> > > Checking the ABI version at build time is not recommended because it
> > > doesn't give any guarantee about the ABI version at run time.  That's
> > > why the ABI should be a dynamic check.
> >
> > But I would like to have a build-time guarantee that certain data
> > structures are available in a certain form or that certain macros
> > exist. Hence my question about build-time checking.
>
> You can check the size of a struct at build time, and then infer which
> fields are part of it.  We should probably add some helpers to make this
> simpler.
>
> It's OK to just copy the header file though.  You'll need to update the
> code to leverage new features anyway.
>
> >
> > > > Currently, I am using a check to see if the compiler can compile the
> > > > struct with `scoped`. [5] However, I don't think this is very elegant.
> > >
> > > If the scoped field is defined, then you should use it and update it at
> > > runtime according to the current Landlock ABI.  See the sandboxer.c
> > > example for such case.
> >
> > But that assumes that the field exists at build time, and that's
> > exactly what I want to check.
>
> sizeof() should help.
>
> >
> > If I try to initialize a non-existent field, there should be an error
> > from the compiler (so I want to catch that beforehand). And if I don't
> > initialize an existing field, clang-tidy complains.
>
> You should always initialize the Landlock structs to zero, otherwise
> you'll get undefined behavior (depending on the content of the stack).
> We can initialize a whole struct with empty curly braces e.g.:
>
>   struct landlock_ruleset_attr ruleset_attr = {};
>
> >
> > As far as I can tell, sandboxer.c always assumes at build time that it
> > has been compiled with a new version. Or am I overlooking something?
>
> That's correct, and it's the case because the landlock.h file is always
> provided with this example, part of the Linux repository.

Re: Question about using Landlock

[Max]

Hi,

On 2025 Nov 20 18:36, Mickaël Salaün wrote:
[... snip ]
>
>Please keep us updated about new sandboxed programs.
>

Do you maintain a list of programs that use landlock?
I'm only aware of zathura [0] that uses landlock (and/or libseccomp) to 
implement a sandbox.
I briefly looked at https://landlock.io/ but couldn't find anything 
there.

[0] https://github.com/pwmt/zathura

-Max

Re: Question about using Landlock

[Mickaël Salaün]

On Fri, Nov 21, 2025 at 04:06:16PM +0100, Max wrote:
> Hi,
> 
> On 2025 Nov 20 18:36, Mickaël Salaün wrote:
> [... snip ]
> > 
> > Please keep us updated about new sandboxed programs.
> > 
> 
> Do you maintain a list of programs that use landlock?
> I'm only aware of zathura [0] that uses landlock (and/or libseccomp) to
> implement a sandbox.
> I briefly looked at https://landlock.io/ but couldn't find anything there.

There were no comprehensive list of sandboxed programs but only
the Landlock newsletters and talks mentioning new ones.

I wrote a new page to help with that and it's now online:
https://landlock.io/integrations/

Feel free to send pull requests to add new projects.

 Mickaël

> 
> [0] https://github.com/pwmt/zathura
> 
> -Max
>