[GH-ISSUE #3992] Enhancement adding lowlevel new sandbox feature "landlock"

gitea-mirror commented

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

Owner

Originally created by @osevan on GitHub (Feb 15, 2021).
Original GitHub issue: https://github.com/netblue30/firejail/issues/3992

Its little bit different than seccomp.

https://lwn.net/Articles/703876/

And

https://landlock.io/

Its.better in my eyes.

I hope someone can study code and plant after in firejail

Thanks and

Best regards

Landlock Versus seccomp

Security debates are the hairiest. They often seem to come out of nowhere, and if you lose the debate, your patch is dead. It's not like other situations, where there are a clear set of interested parties and maybe your feature will have to be changed, but at least your use case will probably end up supported in some fashion. With security issues, you might have a perfectly valid need, and it will simply never be met.

MickaÎl Sala¸n posted a patch for Landlock recently that ran into some trouble. The Landlock security module draws a hard line between a given process and the rest of the system. Even a completely compromised process, if it's landlocked, can't escape to infect the rest of the system. The dream is for user processes to landlock themselves, and then, presto, there is no possibility of a security problem.

But there are circumstances – maybe obviously so – where landlocked processes might want to communicate with each other. MickaÎl's patch would set up a tightly constrained handshaking mechanism to allow landlocked processes to access each other under certain circumstances. For example, one process might debug another. Without any possibility of interprocess communication, this would remain impossible.

But Andy Lutomirski felt that these patches, and perhaps the entire Landlock module, were redundant with the seccomp security module. Instead of implementing a whole new set of security features, he argued, MickaÎl should focus his efforts on coding these same features for seccomp. Although seccomp was originally intended to block system calls, Andy indicated he was open to Landlock-esque extensions.

However, MickaÎl pointed out that his was actually the more sophisticated project. As he put it, "Landlock is more complex than seccomp, because of its different goal. seccomp is less restrictive, because it is more simple."

It did no good. Whatever argument MickaÎl made in favor of Landlock – for example adding easy sandboxes to larger applications or creating whole sandbox managers – Andy simply said that if these features were useful, they would be useful as additions to seccomp. As Andy put it, seccomp was already a living project engaged in exactly this sort of thing, and it would be wasteful to duplicate the effort and care going into it. MickaÎl did agree that his Landlock features would be valuable for seccomp, though he still wanted to keep the projects separate.

It's rough when the gatekeeper for your patch wants you to refocus your efforts on their own pet project, but such things have happened before, and to some extent, that's the way it's supposed to be. Redundant work does need to be identified and its efforts redirected more productively. Sometimes this means a developer must redo many hours of work and accept design decisions and implementation assumptions that they disagree with.

Sometimes developers can disagree so strongly that they will maintain their own alternative for years without backing down. In the late 1990s, Richard Gooch maintained his Devfs project for years against staunch opposition from Greg Kroah-Hartman, who favored the udev project. Eventually the udev project won out, but not before years of flame wars and bitterness were logged forever in the mailing list archives.

Originally created by @osevan on GitHub (Feb 15, 2021). Original GitHub issue: https://github.com/netblue30/firejail/issues/3992 Its little bit different than seccomp. https://lwn.net/Articles/703876/ And https://landlock.io/ Its.better in my eyes. I hope someone can study code and plant after in firejail Thanks and Best regards Landlock Versus seccomp Security debates are the hairiest. They often seem to come out of nowhere, and if you lose the debate, your patch is dead. It's not like other situations, where there are a clear set of interested parties and maybe your feature will have to be changed, but at least your use case will probably end up supported in some fashion. With security issues, you might have a perfectly valid need, and it will simply never be met. MickaÎl Sala¸n posted a patch for Landlock recently that ran into some trouble. The Landlock security module draws a hard line between a given process and the rest of the system. Even a completely compromised process, if it's landlocked, can't escape to infect the rest of the system. The dream is for user processes to landlock themselves, and then, presto, there is no possibility of a security problem. But there are circumstances – maybe obviously so – where landlocked processes might want to communicate with each other. MickaÎl's patch would set up a tightly constrained handshaking mechanism to allow landlocked processes to access each other under certain circumstances. For example, one process might debug another. Without any possibility of interprocess communication, this would remain impossible. But Andy Lutomirski felt that these patches, and perhaps the entire Landlock module, were redundant with the seccomp security module. Instead of implementing a whole new set of security features, he argued, MickaÎl should focus his efforts on coding these same features for seccomp. Although seccomp was originally intended to block system calls, Andy indicated he was open to Landlock-esque extensions. However, MickaÎl pointed out that his was actually the more sophisticated project. As he put it, "Landlock is more complex than seccomp, because of its different goal. seccomp is less restrictive, because it is more simple." It did no good. Whatever argument MickaÎl made in favor of Landlock – for example adding easy sandboxes to larger applications or creating whole sandbox managers – Andy simply said that if these features were useful, they would be useful as additions to seccomp. As Andy put it, seccomp was already a living project engaged in exactly this sort of thing, and it would be wasteful to duplicate the effort and care going into it. MickaÎl did agree that his Landlock features would be valuable for seccomp, though he still wanted to keep the projects separate. It's rough when the gatekeeper for your patch wants you to refocus your efforts on their own pet project, but such things have happened before, and to some extent, that's the way it's supposed to be. Redundant work does need to be identified and its efforts redirected more productively. Sometimes this means a developer must redo many hours of work and accept design decisions and implementation assumptions that they disagree with. Sometimes developers can disagree so strongly that they will maintain their own alternative for years without backing down. In the late 1990s, Richard Gooch maintained his Devfs project for years against staunch opposition from Greg Kroah-Hartman, who favored the udev project. Eventually the udev project won out, but not before years of flame wars and bitterness were logged forever in the mailing list archives.

gitea-mirror

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

closed this issue
added the
enhancement

duplicate
labels

gitea-mirror commented

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

Author

Owner

@topimiettinen commented on GitHub (Feb 15, 2021):

Seccomp can't dereference pointers, for example to file system paths, but Landlock as a LSM could of course do this. Landlock seem to be geared to file system access control: deny access to a path, make a path read only, deny execute rights and so on. There seems to be also a restriction for ptrace().

Firejail also implements similar access control but it uses mount namespaces. There each path component is overmounted with inaccessible content for denying access, or the mount flags are changed for read only or no-execute access. So there's a lot of overlap. The positive side of this is that Firejail could implement the file system restrictions with either Landlock, mount namespaces or even both and for example the profiles would not need to change at all.

The downside is that there would not be much additional benefit. Either method (mount namespaces or Landlock) can implement the file system access controls. With mount namespaces, an attacker may be able to revert some mount namespace operations, provided that they have the necessary CAP_SYS_ADMIN capability, which may not be the case normally. With Landlock it's probably not possible (like seccomp) to get rid of the restrictions once they are in force, except maybe by remounting the file systems at a different path (also requiring CAP_SYS_ADMIN capability).

One great advantage of Landlock would be that (unlike mount operations) its operations are unprivileged. If Firejail was only about managing file systems and used Landlock exclusively, it could be even installed without set-uid bit. But there are other things which need privileges, like network namespaces and mounting AppImages, so this model probably would not be very usable.

Not many things use ptrace(), so using seccomp for dropping the system call entirely may be an acceptable alternative without Landlock.

Does any distro provide a Landlock-enabled kernel yet?

The political rants about kernel development model are not helpful.

@topimiettinen commented on GitHub (Feb 15, 2021): Seccomp can't dereference pointers, for example to file system paths, but Landlock as a LSM could of course do this. Landlock seem to be geared to file system access control: deny access to a path, make a path read only, deny execute rights and so on. There seems to be also a restriction for ptrace(). Firejail also implements similar access control but it uses mount namespaces. There each path component is overmounted with inaccessible content for denying access, or the mount flags are changed for read only or no-execute access. So there's a lot of overlap. The positive side of this is that Firejail could implement the file system restrictions with either Landlock, mount namespaces or even both and for example the profiles would not need to change at all. The downside is that there would not be much additional benefit. Either method (mount namespaces or Landlock) can implement the file system access controls. With mount namespaces, an attacker may be able to revert some mount namespace operations, provided that they have the necessary CAP_SYS_ADMIN capability, which may not be the case normally. With Landlock it's probably not possible (like seccomp) to get rid of the restrictions once they are in force, except maybe by remounting the file systems at a different path (also requiring CAP_SYS_ADMIN capability). One great advantage of Landlock would be that (unlike mount operations) its operations are unprivileged. If Firejail was only about managing file systems and used Landlock exclusively, it could be even installed without set-uid bit. But there are other things which need privileges, like network namespaces and mounting AppImages, so this model probably would not be very usable. Not many things use ptrace(), so using seccomp for dropping the system call entirely may be an acceptable alternative without Landlock. Does any distro provide a Landlock-enabled kernel yet? The political rants about kernel development model are not helpful.

gitea-mirror commented

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

Author

Owner

@osevan commented on GitHub (Feb 15, 2021):

Seccomp can't dereference pointers, for example to file system paths, but Landlock as a LSM could of course do this. Landlock seem to be geared to file system access control: deny access to a path, make a path read only, deny execute rights and so on. There seems to be also a restriction for ptrace().

Firejail also implements similar access control but it uses mount namespaces. There each path component is overmounted with inaccessible content for denying access, or the mount flags are changed for read only or no-execute access. So there's a lot of overlap. The positive side of this is that Firejail could implement the file system restrictions with either Landlock, mount namespaces or even both and for example the profiles would not need to change at all.

The downside is that there would not be much additional benefit. Either method (mount namespaces or Landlock) can implement the file system access controls. With mount namespaces, an attacker may be able to revert some mount namespace operations, provided that they have the necessary CAP_SYS_ADMIN capability, which may not be the case normally. With Landlock it's probably not possible (like seccomp) to get rid of the restrictions once they are in force, except maybe by remounting the file systems at a different path (also requiring CAP_SYS_ADMIN capability).

One great advantage of Landlock would be that (unlike mount operations) its operations are unprivileged. If Firejail was only about managing file systems and used Landlock exclusively, it could be even installed without set-uid bit. But there are other things which need privileges, like network namespaces and mounting AppImages, so this model probably would not be very usable.

Not many things use ptrace(), so using seccomp for dropping the system call entirely may be an acceptable alternative without Landlock.

Does any distro provide a Landlock-enabled kernel yet?

The political rants about kernel development model are not helpful.

You can look here maybe already patched versions there : https://github.com/landlock-lsm/linux/tree/landlock-v28

https://lore.kernel.org/lkml/20210202162710.657398-1-mic@digikod.net/

https://landlock.io/linux-doc/landlock-v28/userspace-api/landlock.html

@osevan commented on GitHub (Feb 15, 2021): > Seccomp can't dereference pointers, for example to file system paths, but Landlock as a LSM could of course do this. Landlock seem to be geared to file system access control: deny access to a path, make a path read only, deny execute rights and so on. There seems to be also a restriction for ptrace(). > > Firejail also implements similar access control but it uses mount namespaces. There each path component is overmounted with inaccessible content for denying access, or the mount flags are changed for read only or no-execute access. So there's a lot of overlap. The positive side of this is that Firejail could implement the file system restrictions with either Landlock, mount namespaces or even both and for example the profiles would not need to change at all. > > The downside is that there would not be much additional benefit. Either method (mount namespaces or Landlock) can implement the file system access controls. With mount namespaces, an attacker may be able to revert some mount namespace operations, provided that they have the necessary CAP_SYS_ADMIN capability, which may not be the case normally. With Landlock it's probably not possible (like seccomp) to get rid of the restrictions once they are in force, except maybe by remounting the file systems at a different path (also requiring CAP_SYS_ADMIN capability). > > One great advantage of Landlock would be that (unlike mount operations) its operations are unprivileged. If Firejail was only about managing file systems and used Landlock exclusively, it could be even installed without set-uid bit. But there are other things which need privileges, like network namespaces and mounting AppImages, so this model probably would not be very usable. > > Not many things use ptrace(), so using seccomp for dropping the system call entirely may be an acceptable alternative without Landlock. > > Does any distro provide a Landlock-enabled kernel yet? > > The political rants about kernel development model are not helpful. You can look here maybe already patched versions there : https://github.com/landlock-lsm/linux/tree/landlock-v28 https://lore.kernel.org/lkml/20210202162710.657398-1-mic@digikod.net/ https://landlock.io/linux-doc/landlock-v28/userspace-api/landlock.html

gitea-mirror commented

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

Author

Owner

@kmk3 commented on GitHub (Feb 18, 2021):

https://lwn.net/Articles/703876/

https://github.com/landlock-lsm/linux/tree/landlock-v28

struct landlock_ruleset_attr ruleset_attr = {
    .handled_access_fs =
        LANDLOCK_ACCESS_FS_EXECUTE |
        LANDLOCK_ACCESS_FS_WRITE_FILE |
        LANDLOCK_ACCESS_FS_READ_FILE |
        LANDLOCK_ACCESS_FS_READ_DIR |
        LANDLOCK_ACCESS_FS_REMOVE_DIR |
        LANDLOCK_ACCESS_FS_REMOVE_FILE |
        LANDLOCK_ACCESS_FS_MAKE_CHAR |
        LANDLOCK_ACCESS_FS_MAKE_DIR |
        LANDLOCK_ACCESS_FS_MAKE_REG |
        LANDLOCK_ACCESS_FS_MAKE_SOCK |
        LANDLOCK_ACCESS_FS_MAKE_FIFO |
        LANDLOCK_ACCESS_FS_MAKE_BLOCK |
        LANDLOCK_ACCESS_FS_MAKE_SYM,
};

Interesting, this appears to be a more granular version of unveil(2):

https://man.openbsd.org/unveil
https://lwn.net/Articles/767137/ ("OpenBSD's unveil()")

Landlock is even mentioned in the comments:

Posted Sep 29, 2018 3:54 UTC (Sat) by TheJH (subscriber, # 101155) Link

This is a large part of the motivation for Mickaël Salaün's Landlock project:
Wanting to allow unprivileged applications to apply custom fine-grained
filesystem access policies to themselves.

Also, this thread:

Posted Sep 29, 2018 18:21 UTC (Sat) by felixfix (subscriber, # 242) Link

Does these self-imposed restrictions apply through fork() and exec()?

If so, it seems an interesting means to have a security wrapper, where you
list all the path and permission restrictions you want to apply, plus the
command you want to run and its args.

runprot /tmp/input r /tmp/output w -- /usr/bin/transmorgify -i /tmp/input -o /tmp/output

Posted Sep 29, 2018 22:34 UTC (Sat) by amarao (subscriber, # 87073) Link

You don't need to create this program. It's exist already. It's called
firejail, and God, I love it. Both per-application profiles and command line
ad-hoc modes are available.

Come to think of it, this comment might have been how I discovered Firejail...

@kmk3 commented on GitHub (Feb 18, 2021): > https://lwn.net/Articles/703876/ > https://github.com/landlock-lsm/linux/tree/landlock-v28 > ```c > struct landlock_ruleset_attr ruleset_attr = { > .handled_access_fs = > LANDLOCK_ACCESS_FS_EXECUTE | > LANDLOCK_ACCESS_FS_WRITE_FILE | > LANDLOCK_ACCESS_FS_READ_FILE | > LANDLOCK_ACCESS_FS_READ_DIR | > LANDLOCK_ACCESS_FS_REMOVE_DIR | > LANDLOCK_ACCESS_FS_REMOVE_FILE | > LANDLOCK_ACCESS_FS_MAKE_CHAR | > LANDLOCK_ACCESS_FS_MAKE_DIR | > LANDLOCK_ACCESS_FS_MAKE_REG | > LANDLOCK_ACCESS_FS_MAKE_SOCK | > LANDLOCK_ACCESS_FS_MAKE_FIFO | > LANDLOCK_ACCESS_FS_MAKE_BLOCK | > LANDLOCK_ACCESS_FS_MAKE_SYM, > }; > ``` Interesting, this appears to be a more granular version of unveil(2): * <https://man.openbsd.org/unveil> * <https://lwn.net/Articles/767137/> ("OpenBSD's unveil()") Landlock is even mentioned in the comments: Posted Sep 29, 2018 3:54 UTC (Sat) by TheJH (subscriber, # 101155) [Link][1] > This is a large part of the motivation for Mickaël Salaün's Landlock project: > Wanting to allow unprivileged applications to apply custom fine-grained > filesystem access policies to themselves. Also, this thread: Posted Sep 29, 2018 18:21 UTC (Sat) by felixfix (subscriber, # 242) [Link][2] > Does these self-imposed restrictions apply through fork() and exec()? > > If so, it seems an interesting means to have a security wrapper, where you > list all the path and permission restrictions you want to apply, plus the > command you want to run and its args. > > runprot /tmp/input r /tmp/output w -- /usr/bin/transmorgify -i /tmp/input -o /tmp/output Posted Sep 29, 2018 22:34 UTC (Sat) by amarao (subscriber, # 87073) [Link][3] > You don't need to create this program. It's exist already. It's called > firejail, and God, I love it. Both per-application profiles and command line > ad-hoc modes are available. Come to think of it, this comment might have been how I discovered Firejail... [1]: https://lwn.net/Articles/767181/ [2]: https://lwn.net/Articles/767226/ [3]: https://lwn.net/Articles/767238/

gitea-mirror commented

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

Author

Owner

@osevan commented on GitHub (May 2, 2021):

Landlock will mainlined in 5.13 kernel.

https://www.phoronix.com/scan.php?page=news_item&px=Linux-5.13-Landlock-Lands

Anyone from firejail team played already with landlock to improve security in fj?

Thanks and

Best regards

@osevan commented on GitHub (May 2, 2021): Landlock will mainlined in 5.13 kernel. https://www.phoronix.com/scan.php?page=news_item&px=Linux-5.13-Landlock-Lands Anyone from firejail team played already with landlock to improve security in fj? Thanks and Best regards

gitea-mirror commented

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

Author

Owner

@osevan commented on GitHub (May 19, 2021):

Here is first Distribution with kernel 5.13

Please test in VM and play with landlock.

https://sypalo.com/how-to-upgrade-ubuntu

https://www.phoronix.com/scan.php?page=news_item&px=Linux-5.13-Landlock-Lands

@osevan commented on GitHub (May 19, 2021): Here is first Distribution with kernel 5.13 Please test in VM and play with landlock. https://sypalo.com/how-to-upgrade-ubuntu https://www.phoronix.com/scan.php?page=news_item&px=Linux-5.13-Landlock-Lands

gitea-mirror commented

2026-05-05 09:11:00 -06:00

Author

Owner

@osevan commented on GitHub (Sep 11, 2021):

Update !

https://lore.kernel.org/linux-security-module/2df4887a-1710-bba2-f49c-cd5b785bb565@digikod.net/T/#u

@osevan commented on GitHub (Sep 11, 2021): Update ! https://lore.kernel.org/linux-security-module/2df4887a-1710-bba2-f49c-cd5b785bb565@digikod.net/T/#u

gitea-mirror commented

2026-05-05 09:11:01 -06:00

Author

Owner

@rusty-snake commented on GitHub (Apr 29, 2022):

Ok, from my playing with Landlock I see the following useful/interesting points:

Restrict exec to a few (well-known) paths.
i.e.
```
noexec /
exec /usr/bin
exec /usr/libexec
```
Restrict creation of files/...
Having a file readable/writeable while hidden/invisible.
Restrict removal of files.

@rusty-snake commented on GitHub (Apr 29, 2022): Ok, from [my playing](https://codeberg.org/crabjail/crablock) with Landlock I see the following useful/interesting points: - Restrict exec to a few (well-known) paths. i.e. ``` noexec / exec /usr/bin exec /usr/libexec ``` - Restrict creation of files/... - Having a file readable/writeable while hidden/invisible. - Restrict removal of files.

gitea-mirror commented

2026-05-05 09:11:02 -06:00

Author

Owner

@rusty-snake commented on GitHub (May 21, 2022):

Has anyone an idea how an landlock integration could look like? Otherwise we can imho close.

@rusty-snake commented on GitHub (May 21, 2022): Has anyone an idea how an landlock integration could look like? Otherwise we can imho close.

gitea-mirror commented

2026-05-05 09:11:02 -06:00

Author

Owner

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

Closing in favour of #5269.

@rusty-snake commented on GitHub (Jul 22, 2022): Closing in favour of #5269.

gitea-mirror referenced this issue

2026-05-05 10:18:37 -06:00

[PR #2499] [MERGED] Add new profile for gnome-schedule #4360

Rows
Columns

[GH-ISSUE #3992] Enhancement adding lowlevel new sandbox feature "landlock" #2499