name matching for .local files when .profiles include others

[jonleivent]

There are profiles in /etc/firejail that do little but include other profiles. This makes the creation of user .local includes somewhat difficult, as the user must read through the /etc/firejail profiles to find the one that does an include of .local, and use that name instead of the target name. It also means that users can't design .local files specific to individual named executables that share .profiles, but must instead create generic ones for all executables that share the same /etc/profile that does an include of .local. I understand the modularity reason to consolidate similar profiles, but this is the side effect.

I hit this recently with the brave browser. I created a ~/.config/firejail/brave-browser.local file, and eventually noticed that it was not included when brave was launched from a menu. On calling brave-browser from the cli, I could see that brave-browser.profile was loading brave.profile, and on inspection of those realized I needed a brave.local file instead of brave-browser.local.

My suggestion is that for .local files, their include should be done by firejail itself instead of relying on an explicit include line in a profile - and that the name of the .local file is chosen the same way that firejail chooses .profiles.

An alternative is to have a macro so that profiles can do something like:
include %NAME.local
where %NAME would expand to the top-level profile name.

[rusty-snake]

If we do this in firejail it self we could also implement --no-locals and --no-globals which would be nice options for debugging.

[jonleivent]

Somewhat related:

I don't know how common it is to try to combine multiple applications in the same firejail sandbox as I am trying (one reason I did that experiment with dbus), but if it is common, then having profiles for applications split up in terms of their whitelisting components vs. their blacklisting components (both file management and capabilities) would be useful. This is because, to run 2 or more apps in the same sandbox, their whitelists must be unioned together. Depending on the purpose for the sandbox, their blacklists may need to be unioned or intersected, or something in between. So having a clear description of the overall whitelist for each app as as distinct profile devoid of blacklist features would be a benefit.