-
Notifications
You must be signed in to change notification settings - Fork 593
Why do we have blacklist, noblacklist, and whitelist in the same profile? #1569
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
Comments
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 Also in response to
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. |
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. |
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 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. |
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. |
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. |
@SpotComms Looks really good. That being said, I think it might be more logical to place |
@Fred-Barclay Edit: I'm bad, I think we can move it to be with the rest. |
Would it? I was assuming that wnb would only whitelist files explicitly noblacklisted in the profile. Including blacklists shouldn't change this.
|
It wouldn't, here it is fixed https://github.com/SpotComms/firejail/commit/07e52cff9ac37fb675891300e300f00564d9f615 |
I like it! Is wnb psuedo-code or do we have a working implementation? |
Hi all! Shouldn't it be easy to simply interpret |
@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 |
@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. |
@smitsohu I'm a bit confused reading that, especially the last part. Ignoring everything:
Assuming I'm not overlooking anything there:
Which proposal breaks backwards compatibility?
?
In which case? |
@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 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. |
Two questions:
BTW: why this? https://github.com/SpotComms/firejail/commit/5370f65d77dc618d4d750a55e9a4cfae3d891a8c |
@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. 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. |
@VladimirSchowalter20 No. If a profile has 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 |
@smitsohu @SpotComms Thx for explanations! |
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. |
Thanks everyone! I think we can close this now. |
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:We then whitelist these files:
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.)
The text was updated successfully, but these errors were encountered: