Why do we have blacklist, noblacklist, and whitelist in the same profile?

[Fred-Barclay]

Is there a particular reason or historical significance for including disable-programs.inc, then noblacklisting the files we need, and then whitelisting those files?
Take the firefox profile for instance. We blacklist quite a few files in ${HOME} with include /etc/firejail/disable-programs.inc, and then noblacklist the ones we need:

noblacklist ~/.config/okularpartrc
noblacklist ~/.config/okularrc
noblacklist ~/.config/qpdfview
noblacklist ~/.kde/share/apps/okular
noblacklist ~/.kde/share/config/okularpartrc
noblacklist ~/.kde/share/config/okularrc
noblacklist ~/.kde4/share/apps/okular
noblacklist ~/.kde4/share/config/okularpartrc
noblacklist ~/.kde4/share/config/okularrc
noblacklist ~/.local/share/gnome-shell/extensions
noblacklist ~/.local/share/okular
noblacklist ~/.local/share/qpdfview
noblacklist ~/.mozilla
noblacklist ~/.pki

We then whitelist these files:

mkdir ~/.mozilla
mkdir ~/.pki
whitelist ${DOWNLOADS}
whitelist ~/.cache/gnome-mplayer/plugin
whitelist ~/.cache/mozilla/firefox
whitelist ~/.config/gnome-mplayer
whitelist ~/.config/okularpartrc
whitelist ~/.config/okularrc
whitelist ~/.config/pipelight-silverlight5.1
whitelist ~/.config/pipelight-widevine
whitelist ~/.config/qpdfview
whitelist ~/.kde/share/apps/okular
whitelist ~/.kde/share/config/okularpartrc
whitelist ~/.kde/share/config/okularrc
whitelist ~/.kde4/share/apps/okular
whitelist ~/.kde4/share/config/okularpartrc
whitelist ~/.kde4/share/config/okularrc
whitelist ~/.keysnail.js
whitelist ~/.lastpass
whitelist ~/.local/share/gnome-shell/extensions
whitelist ~/.local/share/okular
whitelist ~/.local/share/qpdfview
whitelist ~/.mozilla
whitelist ~/.pentadactyl
whitelist ~/.pentadactylrc
whitelist ~/.pki
whitelist ~/.vimperator
whitelist ~/.vimperatorrc
whitelist ~/.wine-pipelight
whitelist ~/.wine-pipelight64
whitelist ~/.zotero
whitelist ~/dwhelper
include /etc/firejail/whitelist-common.inc
include /etc/firejail/whitelist-var-common.inc

Instead of having to blacklist so many files, then noblacklist the ones we need, and then whitelist the those files, why not just keep the whitelist filter and do away with including disable-programs.inc and the noblacklist filter? Since whitelist effectively blacklists all files except the ones it's given, this would have the same effect as what we're already doing but greatly reduce the complexity of many profiles.

Thoughts? Am I missing something?
(Credits to this poster for pointing this out.)

[SkewedZeppelin]

If a user wants to let a program access files in another directory and they decide to disable the whitelist in a local copy, the profile will still be restricted from reading the contents of other programs (which is good!). If blacklist wasn't included and they disabled whitelist, it'd have (near) full access to their home directory (which is very bad!).

At least that is why I always do both. Even when I create a profile with private enabled I'll still try to do both blacklist and whitelist.

Also in response to

There are 200 profiles that do include the disable-programs.inc file but don't have a whitelist rule. That basically means for those programs it hasn't been figured out yet what directories they specifically need access to—only that they shouldn't access some

Some profiles will simply never ever be whitelisted. If you whitelisted your photo viewer then you would only ever be able to view pictures in ~/Photos, what about everywhere else on your system? Same for a music player, yes some people might have music in ~/Music, but others might have an entire drive for music (or three!) or even a nas.

So please anyone reading this, don't make a PR removing blacklist from all the whitelisted profiles.

[Fred-Barclay]

Some profiles will simply never ever be whitelisted.

Good point. I already responded much to the same effect. Whitelisting is really good when we only need to access a (relatively) static portion of the filesystem. It's less than useful for other cases.

I like your perspective! I hadn't thought about a user taking the profile and disabling whitelists - definitely the blacklist provides a fail-safe and keeps files that really should be secret, secret. The question now is if it's worth the extra complexity to protect against this edge case. I'm tending to think that it is.

[SkewedZeppelin]

I think it is, but that doesn't mean we can't simplify it. Since the files that are whitelisted are usually noblacklisted adding a whitelist-noblacklisted would remove the redundancy of having both noblacklist and whitelist for a file/folder.

Example here

The gain isn't much, distribution wise text compresses extremely well, and as for installed disk space an extra 20kb savings isn't much benefit. I guess it could somewhat help with manageability of the profile however.

[Fred-Barclay]

It might not save too much space but that's a really cool idea! It would also reduce the chance of typos when whitelisting a profile.

[SkewedZeppelin]

I think I've done it now, see https://github.com/SpotComms/firejail/commit/b0ccd3ffd3bf4a8502af300e52906c539d0876b7. Its dependent on https://github.com/SpotComms/firejail/commit/12fb6c82c73a76a5587da907873e8916bafb7b46.

[Fred-Barclay]

@SpotComms Looks really good. That being said, I think it might be more logical to place whitelist-noblacklist right after the mkdir commands and just before any whitelist commands, just to keep all the whitelist operations in the same place in the profile. What do you think?

[SkewedZeppelin]

@Fred-Barclay if whitelist-noblacklist wasn't placed where it was, it'd whitelist everything blacklisted by all of the include /etc/firejail/disable-*.inc's. Placing it anywhere else would make the code side of this much harder to implement.

Edit: I'm bad, I think we can move it to be with the rest.

[Fred-Barclay]

Would it? I was assuming that wnb would only whitelist files explicitly noblacklisted in the profile. Including blacklists shouldn't change this.

blacklist <specific files>
include some-blacklist-filter.inc
noblacklist files-that-are-needed

mkdir XYZ
whitelist-noblacklist all files that are noblacklisted
whitelist other files

[SkewedZeppelin]

It wouldn't, here it is fixed https://github.com/SpotComms/firejail/commit/07e52cff9ac37fb675891300e300f00564d9f615

[Fred-Barclay]

I like it! Is wnb psuedo-code or do we have a working implementation?

[smitsohu]

Hi all! Shouldn't it be easy to simply interpret whitelist also as noblacklist? I think this has been proposed already elsewhere, but I can't find it right now.

[SkewedZeppelin]

@Fred-Barclay We'll need someone to implement it. Just store the noblacklist paths in an array temporarily and if whitelist-noblacklist is detected to loop through the array and whitelist them.

@smitsohu that would be a different approach, but then disable-*.inc would have to be after whitelist. And again keeping the ability to disable whitelist and still have stuff blacklisted is a goal.

Edit: see the latest version here

[smitsohu]

@SpotComms Blacklisting files in whitelisted folders would be still possible. And even though the whitelist block could move in front of disable-*.inc and replace noblacklist there, we would keep our backwards compatibility.

The downside is indeed, that if someone decided to remove whitelisting from a profile, the fallback level would not be a safe and working blacklisted profile, as with your proposal, but a safe and broken one (this is what you meant in your previous post, right?). The "profile-ergonomics" would be worse in such a case.

[SkewedZeppelin]

@smitsohu I'm a bit confused reading that, especially the last part.

Ignoring everything:

1. Currently profiles have either blacklist or blacklist + whitelist.
2. @Fred-Barclay and others on the Linux Mint forum are asking why we shouldn't just remove noblacklist and disable-programs.inc from all profiles with whitelist (eg. c307fd7)
3. My response is that doing so would result in less security for the case where a user disables whitelist in a local copy of a profile
4. My compromise is to simply remove the redundancy of both noblacklisting and whitelisting a file/folder by introducing a new option whitelist-noblacklisted
5. The whitelist-noblacklisted option simply whitelists everything that was noblacklisted
6. A partial implementation (eg. no code) of that can be seen https://github.com/SpotComms/firejail/commit/c04dbefdccad0ab7c8a5ca237c4e16372c012d6b
7. Your proposal of simply having whitelist perform what noblacklist does would be bad for the same reason as 2, and would also require moving whitelist before all of the disable-*.inc's

Assuming I'm not overlooking anything there:

we would keep backwards compatibility.

Which proposal breaks backwards compatibility?

but a safe and broken one

?

The "profile-ergonomics" would be worse in such a case.

In which case?

[smitsohu]

@SpotComms sorry for being confusing (night was short). Let me try to shed some light:

to 7: No, it is neutral from a security perspective, because disable-programs.inc can be left in place. It just takes away some command atomicity (instead of noblacklist-blacklist-whitelist, it is enough to have whitelist-blacklist).... and I don't see the use case for explicitly whitelisting a blacklisted path. Note that everything else with regard to blacklisting and whitelisting is still possible.

Backwards compatibility with profiles is kept, because if the whitelist block is not moved in front of disable-*.inc, a condition noblacklist OR whitelist falls back to the old behaviour.

Disabling the whitelisting inside a profile altogether would make it necessary to rename whitelist to noblacklist. This is less ergonomic (and intuitive) than just commenting an option, and insofar your proposal is better.

I hope it is a little clearer now.

[ghost]

Two questions:

1. Does the new approach means that using noblacklist ~/foo in profile would be equivalent of whitelist ~/foo? Using whitelist option in profile means that you have to do it for all needed files. What if we want to exclude only one specific file from blacklist without using whitelist approach?

2. As whitelists works per top directory does using noblacklist /var/foo would mean that all /var directory is in whitelist mode (see above)

BTW: why this? https://github.com/SpotComms/firejail/commit/5370f65d77dc618d4d750a55e9a4cfae3d891a8c

[smitsohu]

@VladimirSchowalter20 No, everything would stay the same as it is now. Except that if you put whitelist in front of blacklist, you can skip the noblacklist step.
Whitelist would imply noblacklist, not the other way round, as you put it in your comment.

But again, the proposal has its drawbacks, another one being that currently noblacklist is often only a subset of whitelist. This means that if we rewrite profiles accordingly, to some degree the transparency is lost which paths are actually blacklisted in disable-*.inc, and which paths are whitelisted only. After thinking it over, I guess I also tend to a new option instead.

[SkewedZeppelin]

@VladimirSchowalter20

No. If a profile has noblacklist ~/foo and you want to make it whitelist instead of adding whitelist ~/foo you can simply add whitelist-noblacklist, meaning if you have 5 noblacklists instead of whitelisting each of them you can just add whitelist-noblacklist. It doesn't change any functionality of blacklist or whitelist, it would just make it easier to maintain the profile.

And https://github.com/SpotComms/firejail/commit/5370f65d77dc618d4d750a55e9a4cfae3d891a8c was necessary for the script I made to create https://github.com/SpotComms/firejail/commit/c04dbefdccad0ab7c8a5ca237c4e16372c012d6b

@smitsohu my proposal wouldn't change anything about placement or about skipping noblacklist.

All my proposal does is remove the redundancy of whitelisting a path when it is already noblacklisted by specifying an option whitelist-noblacklisted. No more, no less.

[ghost]

@smitsohu @SpotComms Thx for explanations!

[netblue30]

The idea is simple: first, we build the whitelisted filesystem, then we blacklist top secret files on the whitelisted filesystem. The order they appear in the profile is important only for "noblacklist". "whitelist" will always be done before "blacklist".

For example if you have a KDE application, you whitelist ~/.kde directory, than you blacklist ~/.kde/share/apps/kwallet.

[Fred-Barclay]

Thanks everyone! I think we can close this now.
@SpotComms I think whitelist-noblacklist would be awesome!