General approach in jailing apps

[githlp]

As i used the sudo firecfg method to firejail the common apps, i stumble upon more and more problems on normal operation with these apps.
What do i mean with "normal operation" ?

Lets take the app nomacs for example. As jailed app nomacs cannot anymore

• open pictures from evolution attachments
• save pictures to my default pictures directory which is $HOME/Bilder
• save any settings like desired language or appearance light/dark theme etc..

What is the purpose in breaking all those standard/needed dir permissions ?

With default profile nomacs is unusable even for basic operation..

[reinerh]

The goal of the default profiles is to cover the most commonly used features. If something commonly used is not working, please open a bug (or better, open a MR 😉). Then it can be fixed in the profile.

If it's some niche feature that's rarely used, it might better to keep it's support out of the profile, if it would mean that the jail is opened too much.
Users that are actually using this feature could then allow it by themselves in the .local override files.

So profiles are often a compromise of functionality that they cover and how tight the jail is.
And often some features are just overlooked by the person who submitted the profile, because they are not using it themselves.

[reinerh]

* save pictures to my default pictures directory which is $HOME/Bilder

The reason for this is that firejail does not know every translation of the default pictures directory.
But it should be possible to set the XDG_PICTURES_DIR environment variable to point to your pictures directory. Then firejail should pick up that location.
(Because the nomacs profile already noblacklists ${PICTURES})

[reinerh]

Also have a look here: https://wiki.archlinux.org/title/XDG_user_directories#Creating_custom_directories

[rusty-snake]

But it should be possible to set the XDG_PICTURES_DIR environment variable to point to your pictures directory.

I think we only parse ~/.config/user-dirs.dirs.

https://github.com/netblue30/firejail/blob/master/src/firejail/macros.c

[rusty-snake]

open pictures from evolution attachments

That's what you want, different programs are isolated against each other. If this is important for you, you can change it (see @reinerh's answer) but if we would allow evolution attachments by default, we must allow evolution, thunderbird, gajim, firefox, chomium, ... open the sandbox to wide. Then somebody would come and ask "Why do you allow all these dangerous things by default?"

save pictures to my default pictures directory which is $HOME/Bilder

This should work if you set it in ~/.config/user-dirs.dirs.

save any settings like desired language or appearance light/dark theme etc.

1. This was overlooked when the profile was created.
2. nomacs changed it's configuration file location (the current profile is eff. 3 years old)

[rusty-snake]

What is the purpose in breaking all those standard/needed dir permissions ?

There are three (at least) opinions on who is responsible for sandboxing (if it isn't enforce by the platform e.g. Android).

1. The developer of the applications, he knows the best what his app requires, when things change and new features are added. However not every developer knows deep insides of a system (e.g. if you only mix a lot frameworks together) and, more important, the most developer want things to "just work" and don't care about security if the are not force to do so (by the platform). So they will just say allow everything so users will not open reports.
2. The admin. However, a lot admin leak knowledge to properly do this and it involves a lot of duplicated work if everyone does the same work.
3. The community (firejail). This isn't perfect either because you always need to make compromises between security and usability for the majority of the users. And you need active people who update and maintain profiles if new hardening features are developed, programs update, .... But I think this "connecting of admin (2.)" is the best we have so far.

All that said, the main reason why things break are

1. it was overlooked when the profile was developed
2. a program update changed required permissions
3. your workflow is to rare to supported by default (if it involves weaking)
4. your system/configuration/... wasn't tested and differs

[githlp]

Thanks a lot for the quick and comprehensive answers.

I did not think about all the changes that come with regular updates and that these need adaption in some possibly long ago build profiles, too.

From an unsophisticated point of view a simple net access block would have done it for a picture viewer/editor as the usual apps on common distributions do not update themselves but get updated from some package management routines.

Both of you made the process and the troubles or needed adjustments now clear, thx again!

I will try to adjust the apps agaic, follow the tip to the XDG_* vars and feedback asap.