search

netblue30 / firejail

Linux namespaces and seccomp-bpf sandbox
https://firejail.wordpress.com
GNU General Public License v2.0
5.69k stars 557 forks source link

Replace "whitelist" and "blacklist" terms by "allowlist" and "blocklist"/"denylist" #4379

Open ned64 opened 3 years ago

ned64 commented 3 years ago

There has been a debate in the IT sec community for a while now about the terms "whitelist" and "blacklist", see e.g. here

dice.com article: ‘Whitelist,’ ‘Blacklist’: The New Debate Over Security Terminology

While certainly not meant by firejail or others in any racial or other negative sense there is at least a potential problem of connotation. "Black" items are to excluded/blocked, while "white" ones will be included/accepted. In a world where there are racism problems in most societies - many of which are about dark and light skin colour - this can be experienced by some as just one more implicit bias of white/black being good/bad.

I therefore suggest that --blacklist options and --whitelist options (including all derivatives) be renamed --blocklist and --allowlist (etc.) as some companies have already started doing.

Alternatively one could use derivatives of allow and deny - terms known from Apache (httpd.conf is where I first came across them decades ago).

In whatever way the change is implemented, the old options would need to be kept (but deprecated a.s.a.p.) as alternative names for existing user configurations not to break, perhaps for quite some time. In all own releases the replacement should be complete, though, including contributed profiles and documentation.

glitsj16 commented 3 years ago

Looks like a duplicate of https://github.com/netblue30/firejail/issues/3447.

ned64 commented 3 years ago

@glitsj16 Well spotted. I did search before posting but it didn't turn up.

glitsj16 commented 3 years ago

I did search before posting but it didn't turn up.

@ned64 That does happen sometimes. Especially with 'keywords' like whitelist and blacklist being all over our code base it can help to run a search through the web search engine of your choosing instead of through the GitHub search.

netblue30 commented 3 years ago

Tentative move to allow/deny under way. I put a message on the main README.md, and redirected the old #3447 issue here.

netblue30 commented 3 years ago

I'm done for now. Everything should be working as before. blacklist/whitelist are set as aliases, nothing should break.

In src/tools/profcleaner.c I have a small tool you can use to convert your local profiles - details in the .c file. Any suggestions in man pages just put them in git. Probably there will be several iterations until we get them right. Hold on on changes throughout the wiki until we release it.

netblue30 commented 3 years ago

Phase 2

"deny" seems to be working, but "allow" sucks!

I was thinking... In Firefox we have the home directory, which is not a real directory, but kind of a virtual one. So instead of "allow" let's put "virtual". How does it sound? Any other ideas?

Also, do we change file names such as whitelist-common.inc? Git blame/history might get confusing.

rusty-snake commented 3 years ago

Any other ideas?

whitelist -> ~allow~ -> strict-allow

Also, do we change file names such as whitelist-common.inc? Git blame/history might get confusing.

allow-*.inc has already an other use, so we would need to rename these to nodeny-*.inc/nodisable-*.inc.

The thing that makes me worry more it that renaming can break user overrides. We can leave redirect-aliases so include whitelist-*.inc in a .local is this working and we can include the old .locals in the renamed one. But what is with ignore include whitelist-runuser-common.inc for example.

Phase 2

Other notes:

netblue30 commented 3 years ago

strict-allow is fine, the best so far!

Let's say we wait until Monday morning in case somebody comes with another idea, and I'll modify the code and the profiles. Then you go in for --help, vim syntax, profile template (we missed it in the first round) and whatever else.

kmk3 commented 3 years ago

@netblue30 commented 12 hours ago:

Phase 2

"deny" seems to be working, but "allow" sucks!

I was thinking... In Firefox we have the home directory, which is not a real directory, but kind of a virtual one. So instead of "allow" let's put "virtual". How does it sound? Any other ideas?

@netblue30 commented 11 hours ago:

strict-allow is fine, the best so far!

Let's say we wait until Monday morning in case somebody comes with another idea, and I'll modify the code and the profiles. Then you go in for --help, vim syntax, profile template (we missed it in the first round) and whatever else.

Hello, I have a proposal for improving the syntax/semantics of the whitelist / allow command (as I also think that it sucks, for multiple reasons) that I've been meaning to submit for a long time.

I haven't submitted it before because the write-up was a little convoluted and I wasn't happy with it, but since these changes are being made, I suppose that now is the time to fix it up and post it.

Anyway, I'll try to do so by Monday (probably on a new issue), so please don't make any more drastic changes until then.

rusty-snake commented 3 years ago

FWIW: There was already a discussion about improved semantic in #3447.

netblue30 commented 3 years ago

Let's keep track of them:

from https://github.com/netblue30/firejail/pull/4388

kmk3 commented 3 years ago

Sorry for not delivering on time. The problems and solutions themselves are basically defined, but overall the text needs more polish and more connections between the paragraphs. Also, the current iteration of fixes/suggestions only came to mind after most of it was written, so I need to refactor some parts.

Here's the current status:

So please bear with me for a few more days (I'm aiming for Friday).

kmk3 commented 3 years ago

(Offtopic)

If you also think that this automatic expansion from #issue_number to [icon issue_title #issue_number](issue url) is a bad idea, please vote on https://github.com/github/feedback/discussions/4321.

netblue30 commented 3 years ago

Thanks @kmk3, absolutely no rush! Let's wait until August 1st, and if necessary we move it again.

kmk3 commented 3 years ago

I have made great and steady progress on the text; this is the current status:

Additionally, today, after copying the quotes and thinking a long time about some other aspects, it came to mind that noblacklist could be (unless I'm missing something) rendered completely obsolete by a new (i.e.: not an alias) command. Now I finally understand why some (seemingly complex/unintuitive) suggestions were made on #3447. I'm glad to have written down 5 different scenarios since the beginning, as this helps test against what the result would look like.

The 2 main problems remain solved either way, but this curve ball means that the solution will have to be adapted for the full set of existing and new commands to make sense.

So, to avoid further delaying what I think is the most urgent step, I have started to work on a PR to fix a related issue, which already was the first action item of my proposal anyway.

(Offtopic)

@kmk3 commented 3 days ago:

(Offtopic)

If you also think that this automatic expansion from #issue_number to [icon issue_title #issue_number](issue url) is a bad idea, please vote on github/feedback#4321.

By the way, I have found a workaround for this: manually linking the issues:

Issue [#3447][3447].

[3447]: https://github.com/netblue30/firejail/issues/3447

So funnily enough, the new troublesome non-standard markdown extension has led me to write markdown in a more standard way (i.e.: avoiding both the old and the new automatic expansions).

kmk3 commented 3 years ago

So yesterday I remembered that private-etc and similar commands also suffer from the same main issue of whitelist, so the Problem 1 section was extended. Besides that, today I noticed 2 more problems specific to these private- commands. Thinking about aliases gave me an idea to solve all of this with two commands instead of over a dozen. These are similar to the other proposed commands and I think that both sets together would greatly help simplify whitelisting overall.

Status:

A few days were spent on #4410 and the rest is basically the same. There are some adjacent topics (mostly related to previous suggestions and future changes) that take a lot of space and need organizing that I might just rip out and only post if they come up.

@kmk3 commented 11 days ago:

Identifies 3 problems with whitelist (and at least one I did not find mentioned on Replace whitelist and blacklist commands with better terms

3447)

I was mistaken about this; while I did not find it explicitly described, there is at least one suggestion in there that takes Problem 1 into consideration.

kmk3 commented 3 years ago
  • Problem 1 extended and split into 1.1 (whitelist) and 1.2 (private-etc et al) / Done
  • 2 new problems (regarding private-etc et al) / Done

The solution section had many disjoint paragraphs and after trying to also solve the above, I decided to rethink the commands and redo it Problem by Problem, step by step. Though not quite done yet, it now makes much more sense and I think I'll leave out most of what was there.

I have spent a large portion of the time trying out the new commands on different kinds of (the existing) profiles (e.g.: allow-*.inc, whitelist-*.inc and normal profiles), to see if they could work and what they would look like.

This helped a lot to notice redundancies/inconsistencies, so the private--related commands are different now. This is probably the biggest change; these commands make more sense now and I think they will be posted as is.

Some questions came up regarding how whitelisting-related commands, running multiple commands at the same time and profile organization would work, as the order of noblacklist and whitelist commands may give different results (not sure). But since the initial problems are still the same and since this would also affect prior suggestions from #3447, I'll either just leave this discussion for the thread or open one separately.

Problem 1 extended and split into 1.1 (whitelist) and 1.2 (private-etc et al) / Done

  • 2 new problems (regarding private-etc et al) / Done

While the former is still true, the latter was not quite correct and requires some changes. I had misunterstood the relationship between whitelist and private- (on keeping vs discarding changes). I think other people might also be confused by this, so I'll open a discussion later to document this.

On the upside, there are fewer commands proposed now, as many of them were due to the above, so things are simpler again.

Summary of the changes that I remember:

Also, there are some discussions that I intend to open separately:

I'd like to open some of them beforehand (even if no answers are posted), to be able to reference them in the post and if they come up in the comments.

I know it's already past the mentioned August 1st date, but there is still work to be done. To be safe, I'm aiming for September 1st. If this would block any ongoing development too much, please let me know.

samuelfmlourenco commented 2 years ago

We shouldn't bend over just because terms that always were acceptable now have a "connotation". It is unproductive and only leads to confusion in the best case, and to a broken system at the worst.