Local option for firecfg.config

[Edu4rdSHL]

Actually firejail handle what profiles create using the firecfg utility reading the /usr/lib/firejail/firecfg.config file. For some reasons users will not want to sandbox some program because of functionality or another reason.

Actually you can just comment out the line of the program name that you don't want to generate and ran firefcg again. The problem is that the /usr/lib/firejail/firecfg.config overwrite in every new firejail installation. We can backup that file in the distro package manager but isn't a good idea since that additional profiles are added and more.

Will be good if we can have a /usr/lib/firejail/firecfg.local file that works in the same way that $profile.local and then you can make something like:

# Local file configuration for firecfg.config
[exclude] # It will exclude the program when generating the symlinks using firecfg
program1
program2
programN
[/exclude]

[include] # It will include the program when generating the symlinks using firecfg
program1
program2
programN
[/include]

Or well:

# Local file configuration for firecfg.config

# It will exclude the program when generating the symlinks using firecfg
exclude program1
exclude program2
exclude programN

# It will include the program when generating the symlinks using firecfg
include program1
include program2
include programN

Or is already a functionality in firejail for doing that?

[FOSSONLY]

Why not:

chattr -i /usr/lib/firejail/firejail.config ? ;)

On the other side, your suggestion would be more comfortable. But don't forget: Yes sandboxing has sometimes a few downsides, but sandbox nearly every program by default is the best possible way of protection. Personally I would write custom rules to some profiles, to circumvent problems.

Nick

[Vincent43]

This is duplicate of #2097 , please continue discussion there.

I believe the best solution is to treat firecfg.config as user editable file similarly to firejail.config: #408

[Edu4rdSHL]

I doesn't see why it's a duplicate, are two different things... I doesn't want it "to be editable by the user" and it isn't the best solution anyways because we are missing the new added profiles. I want a .local option to preserve local changes/configuration maintaining the benefit of the new added profiles.

As note, installing firecfg.config in a place of the user home just will break firejail for packaging. We can use a .local option in $HOME/.local/lib/firejail/firecfg.local and it will be a better solution.

[rusty-snake]

@Edu4rdSHL #408 is about storing it in /etc/firejail and not under $HOME. @Vincent43 say it's a duplcate of #2097. #2097 is about ignoring some entrys in firecfg.config and adding some other (firecfg.allow, firecfg.deny, ...)

PS: you can allways create manualy a symlink sudo ln -s /usr/bin/firejail /usr/local/bin/PROGRAM

[Vincent43]

@Edu4rdSHL It's duplicate because it points to the same problem. What's the best solution for it is debatable - please add your propositions in mentioned ticket. It doesn't make sense to keep every proposed solution in separate ticket because it make all discussions fragmented and in the end only one idea will be implemented.

I disagree with your stance about firecfg.local which is similar to how we handle profiles. firecfg.config is more comparable with firejail.config and we don't have firejail.local there. firejail.config is marked for backup in distro packages and users are already familiar with need to track changes in it from time to time. IMO treating firecfg.config in the same way would be consistent.