github-starred/firejail

Fork 0

mirror of https://github.com/netblue30/firejail.git synced 2026-05-15 14:16:14 -06:00

[GH-ISSUE #5455] proposal: Deprecate blacklist/noblacklist #3002

New issue

Open

opened 2026-05-05 09:39:24 -06:00 by gitea-mirror · 5 comments

gitea-mirror commented

2026-05-05 09:39:24 -06:00

Owner

Originally created by @WhyNotHugo on GitHub (Nov 5, 2022).
Original GitHub issue: https://github.com/netblue30/firejail/issues/5455

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 https://github.com/netblue30/firejail/issues/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.

Originally created by @WhyNotHugo on GitHub (Nov 5, 2022). Original GitHub issue: https://github.com/netblue30/firejail/issues/5455 ### 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 https://github.com/netblue30/firejail/issues/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.

gitea-mirror added the

enhancement

label 2026-05-05 09:39:24 -06:00

gitea-mirror commented

2026-05-05 09:39:27 -06:00

Author

Owner

@WhyNotHugo commented on GitHub (Nov 5, 2022):

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

@WhyNotHugo commented on GitHub (Nov 5, 2022): 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 ```

gitea-mirror commented

2026-05-05 09:39:27 -06:00

Author

Owner

@rusty-snake commented on GitHub (Nov 5, 2022):

See #3447 for mask, allow and deny.

@rusty-snake commented on GitHub (Nov 5, 2022): See #3447 for `mask`, `allow` and `deny`.

gitea-mirror commented

2026-05-05 09:39:28 -06:00

Author

Owner

@WhyNotHugo commented on GitHub (Nov 5, 2022):

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 https://github.com/netblue30/firejail/pull/5453#issuecomment-1304536308 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?

@WhyNotHugo commented on GitHub (Nov 5, 2022): 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 https://github.com/netblue30/firejail/pull/5453#issuecomment-1304536308 _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?

gitea-mirror commented

2026-05-05 09:39:29 -06:00

Author

Owner

@droidmonkey commented on GitHub (Nov 12, 2022):

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.

@droidmonkey commented on GitHub (Nov 12, 2022): 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.

gitea-mirror commented

2026-05-05 09:39:30 -06:00

Author

Owner

@ghost commented on GitHub (Nov 17, 2022):

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.

@ghost commented on GitHub (Nov 17, 2022): 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.

gitea-mirror referenced this issue

2026-05-05 10:23:17 -06:00

[PR #3002] [MERGED] Profiles: add signal-cli profile #4607

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/firejail#3002

No description provided.

Rows
Columns