-
Notifications
You must be signed in to change notification settings - Fork 557
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
proposal: Deprecate blacklist/noblacklist #5455
Comments
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 The fact that
|
See #3447 for |
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 That said, I think the pattern mentioned in #5453 (comment) should work:
Is it an intentional design choice for this to be unsupported, or merely by coincidence? Can it be changed? |
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:
Why make me repeat? Why not a simple command like:
or make commands composable like:
FWIW, I agree with the shift to the new terms, and firejail should really adopt a deny-all-by-default mentality. |
Hello. Hope everyone is fine. First thank you everyone for the amazing job with this tool. 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; » 2. 'Revert' the logic of Whitelist and Blacklist; program.profile:
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. 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. |
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
asnoblacklist X
. This required repetition is kind of an indicator that things are no ideal.Describe the solution you'd like
Drop
blacklist
andnoblacklist
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 /
andtmpfs /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 astmpfs /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 bytmpfs /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 beenblacklisted
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.
The text was updated successfully, but these errors were encountered: