[GH-ISSUE #5269] Add Landlock support

gitea-mirror commented

2026-05-05 09:36:10 -06:00

Owner

Originally created by @ChrysoliteAzalea on GitHub (Jul 22, 2022).
Original GitHub issue: https://github.com/netblue30/firejail/issues/5269

Hello everyone! I've been using Firejail for a long time. I like it sandboxing features that use namespaces, seccomp and AppArmor policies. However, as far as I understand, Firejail doesn't construct a file hierarchy for a mount namespace -- it uses the host FS instead, remounting protected directories with tmpfs or empty/inaccessible directories. It also has limited support for AppArmor, because it can only transition to a pre-defined profile.

Describe the solution you'd like

I propose adding Landlock support to enhance security of the sandbox. Landlock is a Linux security module that implements file access self-restriction in the way that seccomp implements syscall access self-restriction. It can be used to restrict access to sensitive paths. I'm thinking of implementing it for Firejail, however, currently I don't know how to do it better in order not to interfere with normal operation.

Describe alternatives you've considered

One of the alternatives is to reconstruct the filesystem hierarchy in the new namespace "from scratch" -- however, that would require serious changes in Firejail source code that would need to be thoroughly tested. Another alternative is to use AppArmor -- however, loading AppArmor requires superuser privileges, and it can lead to vulnerabilities.

Additional context

I've created an experimental patch for Bubblewrap that implements Landlock self-restriction in order to enhance sandbox security.

Originally created by @ChrysoliteAzalea on GitHub (Jul 22, 2022). Original GitHub issue: https://github.com/netblue30/firejail/issues/5269 ### Is your feature request related to a problem? Please describe. Hello everyone! I've been using Firejail for a long time. I like it sandboxing features that use namespaces, seccomp and AppArmor policies. However, as far as I understand, Firejail doesn't construct a file hierarchy for a mount namespace -- it uses the host FS instead, remounting protected directories with tmpfs or empty/inaccessible directories. It also has limited support for AppArmor, because it can only transition to a pre-defined profile. ### Describe the solution you'd like I propose adding Landlock support to enhance security of the sandbox. Landlock is a Linux security module that implements file access self-restriction in the way that seccomp implements syscall access self-restriction. It can be used to restrict access to sensitive paths. I'm thinking of implementing it for Firejail, however, currently I don't know how to do it better in order not to interfere with normal operation. ### Describe alternatives you've considered One of the alternatives is to reconstruct the filesystem hierarchy in the new namespace "from scratch" -- however, that would require serious changes in Firejail source code that would need to be thoroughly tested. Another alternative is to use AppArmor -- however, loading AppArmor requires superuser privileges, and it can lead to vulnerabilities. ### Additional context I've created an [experimental patch for Bubblewrap](https://github.com/containers/bubblewrap/pull/519) that implements Landlock self-restriction in order to enhance sandbox security.

gitea-mirror

2026-05-05 09:36:10 -06:00

closed this issue
added the
enhancement
label

gitea-mirror commented

2026-05-05 09:36:13 -06:00

Author

Owner

@osevan commented on GitHub (Jul 25, 2022):

I hope someone from FJ team can help you planting landlock lsm, because its must have feature..

Another qestion, can host access to unix sockets Inside landkock?

Or how is possible application communications?

@osevan commented on GitHub (Jul 25, 2022): I hope someone from FJ team can help you planting landlock lsm, because its must have feature.. Another qestion, can host access to unix sockets Inside landkock? Or how is possible application communications?

gitea-mirror commented

2026-05-05 09:36:14 -06:00

Author

Owner

@topimiettinen commented on GitHub (Jul 27, 2022):

Ideally all allow/whitelisting, deny/blacklisting, noexec, read-only, private-bin etc. operations specified in the existing profiles should be translated to corresponding Landlock restrictions (read, write, execute) automatically. That way the profiles probably would not need any changes. Do you think that would be possible?

I think Landlock could one day replace bind mounting (which needs superuser privileges) and then perhaps Firejail could work without being SUID root.

@topimiettinen commented on GitHub (Jul 27, 2022): Ideally all allow/whitelisting, deny/blacklisting, `noexec`, `read-only`, `private-bin` etc. operations specified in the existing profiles should be translated to corresponding Landlock restrictions (read, write, execute) automatically. That way the profiles probably would not need any changes. Do you think that would be possible? I think Landlock could one day replace bind mounting (which needs superuser privileges) and then perhaps Firejail could work without being SUID root.

gitea-mirror commented

2026-05-05 09:36:15 -06:00

Author

Owner

@ChrysoliteAzalea commented on GitHub (Jul 27, 2022):

Ideally all allow/whitelisting, deny/blacklisting, noexec, read-only, private-bin etc. operations specified in the existing profiles should be translated to corresponding Landlock restrictions (read, write, execute) automatically. That way the profiles probably would not need any changes. Do you think that would be possible?

I think it's definitely possible. However, as far as I know, these operations differ in details, so I think that it's worth providing both options (namespacing and Landlock).

I think Landlock could one day replace bind mounting (which needs superuser privileges) and then perhaps Firejail could work without being SUID root.

A process doesn't need actual superuser in order to bind mount -- it just needs a separate user namespace with local CAP_SYS_ADMIN permission (not needing the system-wide CAP_SYS_ADMIN permission) and a separate mount namespace. Bubblewrap does that.

@ChrysoliteAzalea commented on GitHub (Jul 27, 2022): > Ideally all allow/whitelisting, deny/blacklisting, `noexec`, `read-only`, `private-bin` etc. operations specified in the existing profiles should be translated to corresponding Landlock restrictions (read, write, execute) automatically. That way the profiles probably would not need any changes. Do you think that would be possible? I think it's definitely possible. However, as far as I know, these operations differ in details, so I think that it's worth providing both options (namespacing and Landlock). > I think Landlock could one day replace bind mounting (which needs superuser privileges) and then perhaps Firejail could work without being SUID root. A process doesn't need actual superuser in order to bind mount -- it just needs a separate user namespace with local CAP_SYS_ADMIN permission (not needing the system-wide CAP_SYS_ADMIN permission) and a separate mount namespace. Bubblewrap does that.

gitea-mirror commented

2026-05-05 09:36:16 -06:00

Author

Owner

@rusty-snake commented on GitHub (Jul 27, 2022):

FWIW: #5157

@topimiettinen this sound good to me in general. However it can become complicated as the filesystem layout is the results of procedural statement which can overlap if you translate them to landlock rules. Nevermind I thing this is a good approach to start with landlick in FJ.

More lanlock (only) based feature can be implemented later then https://github.com/netblue30/firejail/issues/3992#issuecomment-1113523984.

@rusty-snake commented on GitHub (Jul 27, 2022): FWIW: #5157 --- @topimiettinen this sound good to me in general. However it can become complicated as the filesystem layout is the results of procedural statement which can overlap if you translate them to landlock rules. Nevermind I thing this is a good approach to start with landlick in FJ. More lanlock (only) based feature can be implemented later then https://github.com/netblue30/firejail/issues/3992#issuecomment-1113523984.

gitea-mirror commented

2026-05-05 09:36:17 -06:00

Author

Owner

@ChrysoliteAzalea commented on GitHub (Aug 14, 2022):

I only want to ask -- in order to simplify working with Landlock rulesets, I've made a library called tinyLL. I'd like to ask, is it a good idea to use it? Or would it be better to add Landlock-related functions to Firejail itself?

@ChrysoliteAzalea commented on GitHub (Aug 14, 2022): I only want to ask -- in order to simplify working with Landlock rulesets, I've made a library called [tinyLL](https://github.com/ChrysoliteAzalea/libtinyLL). I'd like to ask, is it a good idea to use it? Or would it be better to add Landlock-related functions to Firejail itself?

gitea-mirror commented

2026-05-05 09:36:18 -06:00

Author

Owner

@rusty-snake commented on GitHub (Aug 14, 2022):

Will it support v2 ABI? (FYI: 86d769797c)

Adding support for an external library in the build system sounds to complex to me (give that it has only ~100 LoC). However adding it to the source tree can be considered.

@rusty-snake commented on GitHub (Aug 14, 2022): Will it support v2 ABI? (FYI: https://codeberg.org/crabjail/crablock/commit/86d769797cfb83761e2e23fcd130e47b01324ac1) Adding support for an external library in the build system sounds to complex to me (give that it has only ~100 LoC). However adding it to the source tree can be considered.

gitea-mirror commented

2026-05-05 09:36:18 -06:00

Author

Owner

@ChrysoliteAzalea commented on GitHub (Aug 14, 2022):

Will it support v2 ABI?

I didn't test it yet (and I don't know whether v2 is in the mainline kernel or not), however, I think I'll try to add support for it. I currently tested tinyLL for Landlock v1. I think I'll add support when my distribution (Linux Mint) start supporting it, or earlier if I manage to upgrade the kernel sooner.

@ChrysoliteAzalea commented on GitHub (Aug 14, 2022): > Will it support v2 ABI? I didn't test it yet (and I don't know whether v2 is in the mainline kernel or not), however, I think I'll try to add support for it. I currently tested tinyLL for Landlock v1. I think I'll add support when my distribution (Linux Mint) start supporting it, or earlier if I manage to upgrade the kernel sooner.

gitea-mirror commented

2026-05-05 09:36:18 -06:00

Author

Owner

@ChrysoliteAzalea commented on GitHub (Aug 15, 2022):

Will it support v2 ABI? (FYI: 86d769797c)

Adding support for an external library in the build system sounds to complex to me (give that it has only ~100 LoC). However adding it to the source tree can be considered.

I'd like to ask, how to add it to the source tree correctly. I've created a pull request, and it works for me, but it seems that currently, it's like libapparmor -- the Firejail builds with Landlock only if tinyLL is already present in the system. I wonder, can it be built and linked automatically, the way it's done with libraries that are in src/lib

@ChrysoliteAzalea commented on GitHub (Aug 15, 2022): > Will it support v2 ABI? (FYI: https://codeberg.org/crabjail/crablock/commit/86d769797cfb83761e2e23fcd130e47b01324ac1) > > Adding support for an external library in the build system sounds to complex to me (give that it has only ~100 LoC). However adding it to the source tree can be considered. I'd like to ask, how to add it to the source tree correctly. I've created a pull request, and it works for me, but it seems that currently, it's like libapparmor -- the Firejail builds with Landlock only if tinyLL is already present in the system. I wonder, can it be built and linked automatically, the way it's done with libraries that are in src/lib

gitea-mirror commented

2026-05-05 09:36:19 -06:00

Author

Owner

@smitsohu commented on GitHub (Nov 22, 2022):

One of the alternatives is to reconstruct the filesystem hierarchy in the new namespace "from scratch" -- however, that would require serious changes in Firejail source code

Currently Firejail modifies the chroot it is running in (as a setuid tool that starts other privileged tools), and this complicates reasoning about code correctness a lot. It would be much easier, if Firejail would build a chroot and then pivot_root into that environment, like some other tools do.

In particular, this would simplify whitelist and some private-* code by a significant margin.

@smitsohu commented on GitHub (Nov 22, 2022): > One of the alternatives is to reconstruct the filesystem hierarchy in the new namespace "from scratch" -- however, that would require serious changes in Firejail source code Currently Firejail modifies the chroot it is running in (as a setuid tool that starts other privileged tools), and this complicates reasoning about code correctness a lot. It would be much easier, if Firejail would build a chroot and then `pivot_root` into that environment, like some other tools do. In particular, this would simplify `whitelist` and some `private-*` code by a significant margin.

gitea-mirror commented

2026-05-05 09:36:19 -06:00

Author

Owner

@kmk3 commented on GitHub (Jan 30, 2024):

Closing, as it was added in #6078.

@kmk3 commented on GitHub (Jan 30, 2024): Closing, as it was added in #6078.

gitea-mirror referenced this issue

2026-05-05 10:23:01 -06:00

[PR #2940] [MERGED] update seccomp in man firejail #4593