Should ~/.local/share/ be blacklisted?

[Fred-Barclay]

As it is now, we tend to blacklist specific files in .local/share and then noblacklist them in the application profile. For example, in disable-programs.inc, ${HOME}/.local/share/epiphany is blacklisted, and then noblacklisted in epiphany.profile. This seems like a bit of a circular approach to me; and besides, every file in ~/.local/share that's not blacklisted is visible to any programme.

Would it be better to simply blacklist ~/.local/share/ entirely and noblacklist/whitelist the subdirectories as needed? It shouldn't take up too much additional code (it actually might reduce the total amount of code) and could benefit the profiles overall.

Thoughts?

[netblue30]

I think we can add another profile command, "standard-app" or something, that will whitelist in ~/.config, ~/.cache and ~/.local only the application directory. For example for vlc, it will leave in only ~/.config/vlc, ~/.cache/vlc and ~/.local/vlc.

[ghost]

Then we'll have problems with folders which aren't named exactly like their programs, like:

Mousepad
roxterm.sourceforge.net
transmission
youtube-dl.conf

But here's a thought I just had. Probably shitty, but "parsing man pages' FILES chapter".

[netblue30]

Let's think about it for a few weeks, we'll figure out something.

[chiraag-nataraj]

We really should switch to a whitelist-based system, at least for the home directory. Most programs only need access to their config files and ~/Downloads. Editors (of various file formats, e.g. libreoffice, emacs, gedit, geany, etc) should have access to ~/Documents as well. Video editors/players should have access to ~/Videos, and audio editors/players to ~/Music. If we also implement #259 as well, then we can use ${VIDEOS} et al instead of hardcoding those. Yes, it's more restrictive, but it's far safer than trying to enumerate and blacklist all "sensitive" files and directories.

[Fred-Barclay]

@chiraag-nataraj I tend to agree but I don't want to cause usability problems, and some programmes probably have a legitimate reason to access somewhat-arbitrary folders -- text editors, for instance. We'd need to take that into account.

[chiraag-nataraj]

idk...I feel like to some extent, it's largely solved by reorganizing your computer a bit and retraining yourself. I've actually been sandboxing my emacs for a while now, and while it's a bit annoying (I ended up writing a helper script which hard-links a file I want to edit into ~/emacs_tmp and removes that file once I'm done editing), it's certainly doable 😉

That being said, I guess we could start switching the more obvious ones first — that is, the ones that don't really need access to more than a small subset of folders. Even if we have a handful of programmes which stick to the current blacklist-based system, switching over the majority to a whitelist-based system would be beneficial, I think.

[chiraag-nataraj]

Also, we should keep in mind that people can always customize the whitelists to be more expansive e.g. for their text editors. So like, just ${HOME}/Documents and ${DOWNLOADS} might be good enough as a default, and people could extend that with other directories in which they frequently edit files. Just spit-balling here.

[jonleivent]

If anyone is still paying attention to this old thread...

I've been a user for a few months, and agree that initial difficulty of deployment of firejail would have made me reluctant to continue with it. However, now that I have some familiarity with it, I'd like a whitelist-based option. My suggestion is to add an option in /etc/firejail/firejail.config to blacklist everything, then rely on .local files to clean up the ensuing mess. With a comment in firejail.config telling newbies to not try this until they're familiar enough with writing .profiles and .locals that they can handle the fallout (and to not complain if they can't ;).

[By the way, is firejail.config overwritten by future updates of firejail? Some installers would detect this and ask whether to keep the old one or not, but I don't know if they all do, nor whether I'd trust myself to always check the diff and not blindly accept the newer version. Maybe have firejail.config include /etc/firejail/firejail-overrides.config that starts life empty and is never overwritten by new versions of firejail?]

I'm tempted to add blacklist ~/* to globals.local and see if I can cope. Then maybe blacklist *. These being the obvious (although user-specific) workarounds to not having a global whitelist-based mode. [But, isn't it the case that all of those individual blacklist entries in default-{programs,common}.inc take some overhead? A whitelist-based mode could instead skip incorporating all blacklist entries unless there was a previous dir-ancestral whitelist entry.] It would also be very helpful if whitelist foo/bar/baz whitelisted foo, foo/bar and foo/bar/baz without whitelisting any of the other contents of foo and foo/bar. Maybe add "whitelist-recurse"?

One reason I'm considering this is because I've made several mistakes when writing new .profiles and .locals (see #3071) that were hard to track down, or even notice - and having blacklist-by-default would have made these much easier to discover. And of course another reason is that I've installed many apps that aren't covered by blacklist entries in default-{programs,common}.inc but which store things in subdirs of ~ that I'd prefer weren't readable by other jailed apps.

As for that idea above about using a hardlink when launching emacs - I like it. Of course it only works within the same filesystem. Maybe do a copy/copy-back instead? That would also allow the truly paranoid to do the copy-back by hand only after diffing to check if emacs, with its nearly infinite cleverness and powers, didn't try to sneak rm -rf / into the initialization script they were editing.

[jonleivent]

This is proving to be very difficult (impossible?) to use blacklist/noblacklist/whitelist/read-only combos to do what I want.

For example, I tried:

firejail --noprofile --noblacklist='~/foo' --blacklist='~/*' --noblacklist=~/foo/bar --blacklist='~/foo/*' --blacklist='~/*' --whitelist=~/foo/bar --read-only=~/foo --read-only=~

expecting to have everything in ~ blacklisted, except ~/foo/bar, with ~/foo read-only and ~/foo/bar writable. But that wasn't what I got: ~/foo/bar was read-only, even though whitelisted while ~/foo was --read-only'ed, even though the man page says this shouldn't happen. Anyway, these sequences of blacklist/noblacklist/whitelist/read-only are going to be a nightmare to get right. BTW - does the doc somewhere spell out how order-sensitive these options are? It's not in the man page.

Also, note this [BTW - this is firejail 0.9.58.2 in debian buster (MX 19)]:

$ firejail --noprofile --blacklist=~ Parent pid 19145, child pid 19146 Error chdir: sandbox.c:1029 sandbox: Permission denied Error: proc 19145 cannot sync with peer: unexpected EOF Peer 19146 unexpectedly exited with status 1

Which makes perfect sense. But it means that one cannot make top-level items in ~ completely invisible to jails (just not readable). Relatedly, if some mischievous jailed app decided to create in ~ some malicious init script that wasn't already there (like .xsession or .xsessionrc), and one hasn't added read-only ~, that would suck - but adding read-only foo, as pointed out above, makes everything below foo read-only apparently without any way to say otherwise. All of which leads me to conclude...

...Private homes are the only way to go. What I will do is put a private ~/jailhomes/app in every app.local, and wrap firecfg in a script that makes sure those private lines exist for all profiles I have set up, adding them if necessary. This will also require that I edit my ~ backup includes/excludes appropriately, and add links back to the real ~ for things I want to access without having to remember which jailhome did what, but that seems like far less of a hassle.

[Vincent43]

You don't need and shouldn't use blacklist when you use whitelist at the same time. whitelist=~/foo/bar is enough to make only ~/foo/bar accessible and nothing else under ~/ top dir.

In general blacklist is used in profiles to make them work for as many users as possible as it's hard to predict all workflows and use cases. For your own profiles where you know which dirs you need to access I recommend to forget about blacklist completely and use whitelist + readonly instead. Using --private= would be even better for security if you don't want to access anything from ~/.

[jonleivent]

The reason I added that whitelist option was to get this:

         A  short  note about mixing --whitelist and --read-only options.
        Whitelisted directories should be made read-only  independently.
        Making a parent directory read-only, will not make the whitelist
        read-only. Example:

        $ firejail --whitelist=~/work --read-only=~ --read-only=~/work

from the firejail man page. Which was the only way I could think of to make a parent dir read-only but make a child dir writable. And which didn't work as advertised. Also note the text error "...the whiltelist read-only." should probably be "...the whitelisted child read-only".

And, the man page doesn't really say what happens with ~/foo when whitelisting ~/foo/bar. Although, with some thought (which admittedly eluded me until now), what else can it do? However, the implication from the above man page example mixing whitelist and read-only suggests there would be a reason to make ~ read-only when ~/work is whitelisted. Or, maybe it's just saying you really only need to do --read-only=~/work, just not saying it well?

OK - lesson learned - I should have done --whitelist=~/foo/bar, which leaves ~/foo writable, but temp-overlayed, so doesn't really matter that it's writable.

But, now I have the --private= scheme working, at least until it doesn't...