Is Firejail really secure?

In lightof this comment, I will start a new thread to learn more about apparmor.

 

I've started playing with Landlock a bit. Remember that it's not available in the current stable Firejail version but only in firejail-git. If you want to try it you should follow the steps here. Remember also that Landlock support is still a work-in-progress so further changes can be expected.

That said, there is some info about Landlock support here. In order to understand its logic it's useful to read what Firejail collaborator rusty-snake wrote here (among other things):

The second point is very important. There is a file landlock-common.inc which contains rules which are aimed to not break existing apps. Now, if you want to test Landlock with, e.g., Firefox you can create the file ~/.config/firejail/firefox.local. Then add the following lines:

Code:

landlock.enforce

include landlock-common.inc

This makes sure that the default rules in that *.inc file will be applied. However, you might think that those rules are too permissive as they grant write permission to your complete home directory. In order to change that you can modify the rules like this:

Code:

landlock.enforce

landlock.write ${HOME}/.cache/mozilla/firefox
landlock.write ${HOME}/.mozilla
landlock.write ${HOME}/.local/share/pki
landlock.write ${HOME}/.pki
landlock.write ${DOWNLOADS}
ignore landlock.write ${HOME}
include landlock-common.inc

So the very broad landlock.write ${HOME} rule will be ignored and replaced by write rules for paths where Firefox needs write permission. Note that this is probably not enough as write permission will also be needed to some other files/directories listed in the whitelist-common.inc file, e.g., for changing fonts. Note also that the first rule in landlock-common.inc, namely landlock.read /, still grants read permission to the whole system - but that's already strictly confined by the other rules in the profile, of course (remember that the Landlock rules are applied additionally to the existing sandboxing techniques in Firejail and do not replace them!). Hence, those rules above are not really necessary, either - they are only an example how to replicate the already existing rules in the profile with equivalent Landlock rules.

There are many ways how to play with those rules. E.g., you could add

Code:

ignore landlock.execute /opt
ignore landlock.execute /usr/local/sbin
ignore landlock.execute /usr/local/games

or even ignore landlock.read / but that would require very detailed read rules to not not break your application.

Again, Landlock support in Firejail (and Landlock development itself!) is still a WIP and it remains exciting how this will evolve. Considering that one of the Firejail colloborators has started working on an unprivileged Firejail version, Landlock can play a very important role in future versions as it allows unprivileged processes to restrict their access to the filesystem

 

Thanks @summerheat

for your info on Landlock. I have verified it's running on my system as found in /var/log/syslog:

Code:

 mx-23 kernel: [    0.085316] landlock: Up and running.

However, I've no idea how to utilize it. The documentation is highly technical and imo not very helpful. Does it only work with a sanboxing solution such as Firejail, or can it be enforced on its own with custom rulesets?

 

Neither do I. I think it's similar to applying seccomp filters or namespaces. Both are highly technical as well and Firejail "translates" that into easily applicable rules. That said, Landlock rules can be directly used by application authors to limit the permissions of the app. We'll see how much this will be adopted in the coming years.

 

Okay thanks!