proposal: Deprecate blacklist/noblacklist

[WhyNotHugo]

Is your feature request related to a problem? Please describe.

Firejail currently suffers from a bit too much complexity, making it hard to understand and audit (both profiles and code-wise, though I'm not the most qualified to comment on that second topic). In particular, the relationship between blacklist and whitelist is very nuanced and hard to fully grasp. It adds lots of surprises like #5450, where whitelisting a directory doesn't whitelist it because one of the several included profile blacklists it.

blacklisting also follows a weird approach for security; usually one would start with a clean slate, and explicitly indicate which permissions are allowed. blacklist work with a mental model of "everything is allows, list things that shouldn't be".

Finally, almost all profiles repeat entries whitelist X as noblacklist X. This required repetition is kind of an indicator that things are no ideal.

Describe the solution you'd like

Drop blacklist and noblacklist entirely.

I understand that some profiles which have a design of "everything is allowed except this particular directory which should be disallowed". These can simply use the directives whitelist / and tmpfs /path/to/restricted/directory to achieve the same result.

Generally, however, profiles should add new whitelist entries conservatively so as to no require blacklisting things inside them.

Looking at common blacklist entries in existing profiles, most of these would actually be served better by more restricted directives instead. For example, blacklist /tmp/.X11-unix could be better expressed as tmpfs /tmp(i.e.: don't even grant access to the host's /tmp unless strictly required).

Another scenario that stands out it disable-interpreters.inc. This, again, follows an unusual principle in security; it's intended to be used in profiles here "all binaries are exposed except these specific ones". These usages would be better served by tmpfs /usr/bin and then only mounting the binaries that are allowed expliclity.

I'm quite open to hearing about specific profiles that cannot be secured without blacklist.

Describe alternatives you've considered

Paths that are explicitly whitelist should be mounted even if they've been blacklisted before. This is less surprising when writing a profile (e.g.: if something is being whitelisted then it should be mounted even if some .inc profile has blacklisted it before).

Additional context

I know this is a delicate request; I'm not creating this ticket making demands, but rather with the expectation of civil conversation around the idea. I've seen mentions of this in a few miscellaneous tickets, but not a proper issue for it.

[WhyNotHugo]

I don't think the blacklist approach is simple enough to scale well, TBH. By default profiles have access to all filesystem paths, and then blacklist removes access, and then some profiles use noblacklist to re-gain access.

However, the fact that whitelist has the side-effect of removing access to other directories that share a top-level parent is also very weird.

The fact that blacklist /some/path blocks whitelist /some/path/to/a/subdirectory is really a weird quirk. For example, this simple pattern wouldn't work:

blacklist $HOME/.config
whitelist $HOME/.config/myapp

[rusty-snake]

See #3447 for mask, allow and deny.

[WhyNotHugo]

Related and close, but those merely refine these concepts rather than trim complexity.

Mostly, what I have in mind is switch from the "all paths allowed by default" approach to "no paths allowed by default". The fact that whitelist /path/to/some/directory removes /path is also a very weird caveat to keep in mind that could also be set aside with such a change.

That said, I think the pattern mentioned in #5453 (comment) should work:

tmpfs ${HOME}/.config/
whitelist ${HOME}/.config/keepassxc

Is it an intentional design choice for this to be unsupported, or merely by coincidence? Can it be changed?

[droidmonkey]

Just posting a comment as an outsider and having not used firejail at all personally... it seems the syntax for firejail is full of idiosyncrasies. For example:

mkdir ${HOME}/protected
allow ${HOME}/protected

Why make me repeat? Why not a simple command like:

mkdir-allow ${HOME}/protected

or make commands composable like:

mkdir + allow ${HOME}/protected

FWIW, I agree with the shift to the new terms, and firejail should really adopt a deny-all-by-default mentality.

[d-keys]

Hello. Hope everyone is fine.

First thank you everyone for the amazing job with this tool.
I've been using it for a while now and it has been really useful.

I first started using Firejail as a study tool to understand the concept of containers and firewalls in Linux environment and the practical-to-config mentality really helped me to learn more about this topic.

Unfortunately, when I decided to use and edit profiles to my cases, this explained design choice about whitelist and blacklist logic didn't work out the way it looked like it should.

Now, I understand that these expressions are subjective to such difficult tasks such as those, thus, I'm just being thankful and humbly asking for the team to considerate this change (if possible and viable also to the rest of the community).

The idea would be simpler to understand, albeit laborious with cases in which configuring profiles for programs that are not on the default profile list is necessary. In any way, I also want to contribute with possible solutions:

» 1. Give the user the choice to block all by default, or allow all by default;
In this case, more experienced users would be able to get what they want: A "firewall like" behaviour, therefore, being able to allow only what they know programs need to access in their system.

» 2. 'Revert' the logic of Whitelist and Blacklist;
In this case, Whitelisting takes priority over Blacklist. Just like @WhyNotHugo explained, this is what I had in mind when I first tried configuring my own profiles.
So, if:

program.profile:

blacklist /
whitelist $HOME/

Program would be able to read everything inside $HOME, but File System / wouldn't be visible.

» 3. Extend "--private" logic giving it more configurable options.
In this case, Private mode could be able to be more configurable in a way that user definitions would allow user to choose if he wants to delete the private session, what parts of the system should this session be allowed to see and use and so on.

Sorry if I extended myself. Just wanting to help with ideas. I understand that those can be hard and time consuming to implement, so Im happy this discussion can even happen in the first place.

Thanks again.