firecfg: allow for ignoring specific apps

[Vincent43]

Currently firecfg unconditionally creates symlinks for all apps it detects. This is problematic if user doesn't want to use specific app with firejail.

I propose allowing users to prevent creating symlinks for chosen apps: firecfg --ignore <app_name>. The database of ignored apps could be saved same way as database of allowed users is currently.

This was discussed before: #1675

[chiraag-nataraj]

How about, instead, have an -a/--all flag which would replicate the behaviour seen here and otherwise, only link the apps listed on the command-line?

[chiraag-nataraj]

This way, you could also use --clean to clean up only specific links or --clean --all to clean all links.

[Vincent43]

Ability to symlink only chosen apps would be useful too but it's something different. Usecase which I have in mind is ignoring one,two or three apps among dozens which is rather hard to type in cmdline in whitelist mode so I prefer blacklisting.

EDIT: just checked that I have over 60 firejail symlinks created with firecfg. Providing all of them in cmdline in order to exempt a few of them isn't reasonable for me.

[chiraag-nataraj]

So maybe have files like firecfg.allow and firecfg.deny (names up for debate)? That way, if you only want to allow specific programs, edit firecfg.allow. If you only want to deny specific programs, edit firecfg.deny. If neither of those exists, we get the existing behavior.

[Vincent43]

That sounds good!

[hlein]

I propose moving firecfg.config under /etc/ - /etc/firejail/firecfg.config, or whatever.

More advanced features like a .local, .deny, .allow, or whatever, are all well and good to keep discussing, but in the meantime I would argue simply: these amount to configuration files, they should go in a path that a) system administrators expect to find configs in and b) distribution packaging tools expect to store configs in, and therefore won't silently overwrite local customizations during version upgrades.

There's multiple issues regarding this - #408 which refers to #2829 which was closed with a comment pointing here.

If I make a PR that relocates firecfg.config from LIBDIR/firejail/ to SYSCONFDIR/firejail/, is it likely to be accepted?

Thanks!

[rusty-snake]

I am strongly in favour of using /etc instead of /usr/lib64 for this and I don't think anyone is against it.

[hlein]

I am strongly in favour of using /etc instead of /usr/lib64 for this and I don't think anyone is against it.

Sweet, thanks! I will work on this as soon as I get a chance.

[rusty-snake]

Interesting workaround: https://github.com/kugland/nojail

[rieje]

Couldn't you just symlink it to the actual binary you want, i.e. /usr/bin/<app>? But I agree, an option to ignore apps so no needless symlinks are needed is ideal.

[rusty-snake]

firecfg.config is now located in /etc/firejail which make overwriting by users easier.

I wanted to add a note in RELNOTES about that but that got me wondering what recommendation we should give distributors

1. Replace user changes (current situation): If a user adds/removes program to/from firecfg.config an update of firejail will undo this.
   • Pro: Users get entries in firecfg.config for new programs
   • Pro: Users get entries in firecfg.config removed if the are known to break
   • Con: User added programs are (silently) now longer jailed
   • Con: User removed programs start breaking again
2. Noreplace user changes: If a user modifies firecfg.config it will not be updated on updated of firejail.
   • Pro: User modifications are still in effect
   • Con: New programs do not get jailed automatically

---

We could solve all this if we do a second relocate and implement a override mechanism.

Proposal:

• Relocate firecfg.config to LIBDIR/firecfg.config back
• Add a /etc/firejail/firecfg.config.local file like:

  # This is a comment
  !firefox        <--- skip firefox
  ffmpeg     <--- add ffmpeg
  

[hlein]

I wanted to add a note in RELNOTES about that but that got me wondering what recommendation we should give distributors

I maintain the Gentoo package of firejail, and we have a very nice mechanism for handling changes to config files: etc-update. It knows which files being deployed/updated count as "config files", and gives a nice menu/diff/editor-based way to merge/arbitrate changes. I believe many other distros have similar mechanisms although maybe they are package-specific.

My next update to the Gentoo package was going to deploy some distro-specific changes to firecfg.config (things I know don't work well on Gentoo for whatever reason, but aren't worth disabling across the board for all firejail installs IMO). Users can also make their own local edits to firecfg.config, and etc-update will prevent stomping on their changes across upgrades.

So, I hope this won't be chosen:

• Relocate firecfg.config to LIBDIR/firecfg.config back

but this would be great:

• Add a /etc/firejail/firecfg.config.local file like:

  # This is a comment
  !firefox        <--- skip firefox
  ffmpeg     <--- add ffmpeg
  

I was going to suggest -, but ! also makes sense.

[rusty-snake]

So, I hope this won't be chosen:

The two points are linked with a logical "and" so both would be done in one PR.

I maintain the Gentoo package of firejail

Great, somebody more I know to ping for packaging issues.

I believe many other distros have similar mechanisms although maybe they are package-specific.

Fedora: If a file is marked as %config, it will be saved as FILENAME.rpmsave if it has user modifications. If it is marked as %config(noreplace), it is installed as FILENAME.rpmnew. There is rpmconf and python3-dnf-plugin-rpmconf which provide such install/keep/diff/... features but they are not installed by default nor do the have an effect if you update your system via gnome-software (what I not recommend to do).

[hlein]

So, I hope this won't be chosen:

The two points are linked with a logical "and" so both would be done in one PR.

But... do they need to be? If we will have a firecfg.config.local for site-local changes (and there's symmetry there for profile .local files), why not let firecfg.config live under /etc/ ? We don't put profiles under LIBDIR, after all.

I maintain the Gentoo package of firejail

Great, somebody more I know to ping for packaging issues.

Sure :)

I believe many other distros have similar mechanisms although maybe they are package-specific.

Fedora: If a file is marked as %config, it will be saved as FILENAME.rpmsave if it has user modifications. If it is marked as %config(noreplace), it is installed as FILENAME.rpmnew. There is rpmconf and python3-dnf-plugin-rpmconf which provide such install/keep/diff/... features but they are not installed by default nor do the have an effect if you update your system via gnome-software (what I not recommend to do).

That sounds sort of painful, but at least it is a thing. I mean really, software deploying default config files that users/admins can modify, and then it's the distro's problem to decide what to do upon upgrading the package, is a normal thing.

[kmk3]

@hlein commented on Nov 15:

So, I hope this won't be chosen:

The two points are linked with a logical "and" so both would be done in one
PR.

But... do they need to be? If we will have a firecfg.config.local for
site-local changes (and there's symmetry there for profile .local files),
why not let firecfg.config live under /etc/ ? We don't put profiles under
LIBDIR, after all.

Considering that firecfg.config is basically just a giant list of programs
(rather than having many individual options like in firejail.config), I also
think that having a separate file for admin modifications would be better, as
it seems that conflicts would happen much more often and that the diff would be
harder to read (compared to that of firejail.config).

I believe many other distros have similar mechanisms although maybe they
are package-specific.

Fedora: If a file is marked as %config, it will be saved as
FILENAME.rpmsave if it has user modifications. If it is marked as
%config(noreplace), it is installed as FILENAME.rpmnew. There is
rpmconf and python3-dnf-plugin-rpmconf which provide such
install/keep/diff/... features but they are not installed by default nor do
the have an effect if you update your system via gnome-software (what I not
recommend to do).

That sounds sort of painful, but at least it is a thing. I mean really,
software deploying default config files that users/admins can modify, and
then it's the distro's problem to decide what to do upon upgrading the
package, is a normal thing.

Agreed.

On Arch, if you tried to install a package that would conflict with a modified
/etc/firejail/firecfg.config, pacman would just save the new version as
/etc/firejail/firecfg.config.pacnew, print a warning and then finish installing
normally. After the install, these files could be compared and merged by
running pacdiff (which would open them in vimdiff by default), if/when you
felt like doing so. Details:

• https://wiki.archlinux.org/title/Pacman/Pacnew_and_Pacsave

IIRC, on Debian apt asks interactively in an ncurses-based UI what to do if a
configuration conflict happens (personally, I'd much rather not have upgrades
interrupted by default just because of that, but I suppose that it could be
useful in places where any breakage at all would be a big problem).

So considering that configuration files like /etc/firejail/firejail.config have
been around for a long time without having .local versions and that at least
apt, emerge, pacman and rpm apparently support conflict resolution in /etc in
seemingly good enough ways, to me it seems that this is a pretty standard
feature of package managers.

[WhyNotHugo]

How about /etc/firejail/firecfg.d/ which can include many files, processed in-order.

So a default 10-default.config can include the current defaults, but one can include overrides such as 20-no-mpv.config with !mpv?

The biggest problem with having to mutate a package-provided file for configuration, is that it does not allow for a second package to ship a configuration file. I can currently have a package which ships a variety of configurations by dropping in files in /etc/modprobe.d/, usr/lib/tmpfiles.d/ , etc. However, it can't provide a file that's already installed by another package.

Sure, scripts could mutate the package-provided /etc/firejail/firecfg.config, but that requires making sure it's kept aligned with new versions after each update somehow. In the end, the idea of "mutable package-provided files" is always tricky. Being able to use drop-in files would solve this (which is what happens with the *.local files now for profiles.

[rusty-snake]

That's what firecfg.py does for 1,5 or 2 years now and it works great.

https://github.com/rusty-snake/firecfg.py/tree/master/firecfgpy/groups

It also solves the privileged-programs/chrom*/file-archivers can not be sandboxed on some systems issue by making own files for the which can be enabled/disable.

[kmk3]

PR created:

• feature: firecfg: add firecfg.d & add ignore command #5876

Feel free to test and review.