mirror of
https://github.com/netblue30/firejail.git
synced 2026-05-15 14:16:14 -06:00
[GH-ISSUE #4379] Replace "whitelist" and "blacklist" terms by "allowlist" and "blocklist"/"denylist" #2642
Labels
No labels
LTS merge
LTS merge
bug
bug
converted-to-discussion
doc-todo
documentation
duplicate
enhancement
file-transfer
firecfg
firejail-in-firejail
firetools
graphics
help wanted
information_old
installation
invalid
modif
moved
needinfo
networking
notabug
notourbug
old-version
overlayfs
packaging
profile-request
pull-request
question
question_old
removal
runtime-permissions
sandbox-ipc
security
stale
wiki
wiki
wontfix
wordpress
workaround
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/firejail#2642
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @ned64 on GitHub (Jun 30, 2021).
Original GitHub issue: https://github.com/netblue30/firejail/issues/4379
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
--blacklistoptions and--whitelistoptions (including all derivatives) be renamed--blocklistand--allowlist(etc.) as some companies have already started doing.Alternatively one could use derivatives of
allowanddeny- terms known from Apache (httpd.confis 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.
@ghost commented on GitHub (Jun 30, 2021):
Looks like a duplicate of https://github.com/netblue30/firejail/issues/3447.
@ned64 commented on GitHub (Jun 30, 2021):
@glitsj16 Well spotted. I did search before posting but it didn't turn up.
@ghost commented on GitHub (Jun 30, 2021):
@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 on GitHub (Jul 1, 2021):
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 on GitHub (Jul 5, 2021):
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 on GitHub (Jul 8, 2021):
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 on GitHub (Jul 8, 2021):
whitelist->allowstrict-allowallow-*.inchas already an other use, so we would need to rename these tonodeny-*.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-*.incin a .local is this working and we can include the old .locals in the renamed one. But what is withignore include whitelist-runuser-common.incfor example.Other notes:
a11707ea27 (r53017801)(typo)fe0f975f44 (r53159540)(double spaces)--helpmessage should be improved. Thought--helpmessage need a rework/review in general, I mean--machine-id - preserve /etc/machine-id.--machine-iddoes the opposite (it creates a new/etc/machine-id).@netblue30 commented on GitHub (Jul 8, 2021):
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 on GitHub (Jul 9, 2021):
@netblue30 commented 12 hours ago:
@netblue30 commented 11 hours ago:
Hello, I have a proposal for improving the syntax/semantics of the
whitelist/
allowcommand (as I also think that it sucks, for multiple reasons) thatI'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 on GitHub (Jul 9, 2021):
FWIW: There was already a discussion about improved semantic in #3447.
@netblue30 commented on GitHub (Jul 11, 2021):
Let's keep track of them:
from https://github.com/netblue30/firejail/pull/4388
@kmk3 commented on GitHub (Jul 13, 2021):
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:
sections and lists)
whitelist(and at least one I did not findmentioned on #3447)
allow/denyusage(and over some others from #3447)
So please bear with me for a few more days (I'm aiming for Friday).
@kmk3 commented on GitHub (Jul 13, 2021):
(Offtopic)
If you also think that this automatic expansion from
#issue_numberto[icon issue_title #issue_number](issue url)is a bad idea, please vote onhttps://github.com/github/feedback/discussions/4321.
@netblue30 commented on GitHub (Jul 13, 2021):
Thanks @kmk3, absolutely no rush! Let's wait until August 1st, and if necessary we move it again.
@kmk3 commented on GitHub (Jul 16, 2021):
I have made great and steady progress on the text; this is the current status:
there are some loose/no longer relevant parts to be removed)
mention some advantages
the mid- or long-term
Additionally, today, after copying the quotes and thinking a long time about
some other aspects, it came to mind that
noblacklistcould be (unless I'mmissing 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:
By the way, I have found a workaround for this: manually linking the issues:
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 on GitHub (Jul 23, 2021):
So yesterday I remembered that
private-etcand similar commands also sufferfrom 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:
whitelist) and 1.2 (private-etcetal) / Done
private-etcet al) / DoneA 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:
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 on GitHub (Aug 2, 2021):
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 biggestchange; 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
noblacklistandwhitelistcommands may give different results (notsure). 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.
While the former is still true, the latter was not quite correct and requires
some changes. I had misunterstood the relationship between
whitelistandprivate-(on keeping vs discarding changes). I think other people might alsobe 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:
ed1f0c088noblacklist+nowhitelist)private-related commands were changed)Also, there are some discussions that I intend to open separately:
whitelistandprivate-noblacklistandignore blacklistI'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 on GitHub (Feb 18, 2022):
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.