[GH-ISSUE #1441] Whitelist isn't really a whitelist...?

gitea-mirror commented

2026-05-05 07:14:39 -06:00

Owner

Originally created by @taoeffect on GitHub (Aug 8, 2017).
Original GitHub issue: https://github.com/netblue30/firejail/issues/1441

I've been reading the docs and the man pages, as well as the issues, and it's starting to dawn on me that there seems to be confusion about what whitelist is/does.

For an illustrative example, see issue #354, and comments within it like this one.

In infosec, a whitelist has a very specific meaning, and its meaning is mutually exclusive from a blacklist. In other words, both cannot exist at the same time, as the words represent two opposite approaches.

I.e. in this GitHub issue field, to protect against XSS attacks, GitHub can either attempt to blacklist certain symbols to sanitize input, or it can whitelist the allowed HTML tags.

Whitelisting is always considered the more secure approach, because it eliminates all possibilities except those explicitly allowed.

However, the firejail online docs clearly indicate that this isn't how how the application is using the term "whitelist":

I also bring in session configuration such as fonts, desktop themes, GTK, Qt etc. by including /etc/firejail/whitelist-common.inc. In the end I also include the default blacklisting configuration from include /etc/firejail/default.profile in order to import the security filters such as seccomp and capabilities.

So the docs, and the term itself, are not clear. The words "whitelist" and "blacklist" can appear in profiles simultaneously, and therefore it's not clear what exactly the purpose of the whitelist keyword is.

From my reading it seems to have more to do with allowing changes to be persisted than the security notion of building a whitelist. So perhaps it should be renamed to persist?

Originally created by @taoeffect on GitHub (Aug 8, 2017). Original GitHub issue: https://github.com/netblue30/firejail/issues/1441 I've been reading the docs and the man pages, as well as the issues, and it's starting to dawn on me that there seems to be confusion about what `whitelist` is/does. For an illustrative example, see issue #354, and comments within it like [this one](https://github.com/netblue30/firejail/issues/354#issuecomment-305996841). In infosec, a **whitelist** has a very specific meaning, and its meaning is *mutually exclusive* from a **blacklist**. In other words, both cannot exist at the same time, as the words represent two opposite approaches. I.e. in this GitHub issue field, to protect against XSS attacks, GitHub can either attempt to blacklist certain symbols to sanitize input, or it can whitelist the allowed HTML tags. Whitelisting is always considered the more secure approach, because it eliminates all possibilities except those explicitly allowed. However, [the firejail online docs](https://firejail.wordpress.com/documentation-2/building-whitelisted-profiles/) clearly indicate that this isn't how how the application is using the term "whitelist": > I also bring in session configuration such as fonts, desktop themes, GTK, Qt etc. by including /etc/firejail/whitelist-common.inc. In the end I also include the default blacklisting configuration from include /etc/firejail/default.profile in order to import the security filters such as seccomp and capabilities. So the docs, and the term itself, are not clear. The words "whitelist" and "blacklist" can appear in profiles simultaneously, and therefore it's not clear what exactly the purpose of the `whitelist` keyword is. From my reading it seems to have more to do with allowing changes to be persisted than the security notion of building a whitelist. So perhaps it should be renamed to `persist`?

gitea-mirror

2026-05-05 07:14:39 -06:00

closed this issue
added the
enhancement
label

gitea-mirror commented

2026-05-05 07:14:44 -06:00

Author

Owner

@ghost commented on GitHub (Aug 8, 2017):

It's what you described at first. When using whitelist everything else under top directory of your whitelist path is automatically blacklisted. Keep in mind that whitelist supports only user $HOME, /dev, /media, /mnt, /opt, /srv, /var, and /tmp top directories and each one is independent of others.

So whitelisting /tmp/aaa blacklist everything inside /tmp except aaa but everything under /opt will be still accesible. This way you can combine whitelist and blacklist among different top directories.

@ghost commented on GitHub (Aug 8, 2017): It's what you described at first. When using `whitelist` everything else under top directory of your whitelist path is automatically blacklisted. Keep in mind that `whitelist` supports only user `$HOME, /dev, /media, /mnt, /opt, /srv, /var, and /tmp` top directories and **each one is independent of others.** So whitelisting `/tmp/aaa` blacklist everything inside `/tmp` except `aaa` but everything under `/opt` will be still accesible. This way you can combine `whitelist` and `blacklist` among different top directories.

gitea-mirror commented

2026-05-05 07:14:46 -06:00

Author

Owner

@taoeffect commented on GitHub (Aug 8, 2017):

Woah. Is that written somewhere or did I just miss it? Seems like critically important info to understand how to use this software!

@taoeffect commented on GitHub (Aug 8, 2017): Woah. Is that written somewhere or did I just miss it? Seems like critically important info to understand how to use this software!

gitea-mirror commented

2026-05-05 07:14:47 -06:00

Author

Owner

@ghost commented on GitHub (Aug 8, 2017):

You can deduce it from the way it works (by mount --bind) described on manpage, which excerpt is also posted in one of your links.

--whitelist=dirname_or_filename
    Whitelist directory or file. A temporary file system is mounted on the top directory, and the whitelisted files are mount-binded inside. Modifications to whitelisted files are persistent, everything else is discarded when the sandbox is closed. The top directory could be user home, /dev, /media, /mnt, /opt, /srv, /var, and /tmp

@ghost commented on GitHub (Aug 8, 2017): You can deduce it from the way it works (by `mount --bind`) described on manpage, which excerpt is also posted in one of your links. ``` --whitelist=dirname_or_filename Whitelist directory or file. A temporary file system is mounted on the top directory, and the whitelisted files are mount-binded inside. Modifications to whitelisted files are persistent, everything else is discarded when the sandbox is closed. The top directory could be user home, /dev, /media, /mnt, /opt, /srv, /var, and /tmp ```

gitea-mirror commented

2026-05-05 07:14:49 -06:00

Author

Owner

@taoeffect commented on GitHub (Aug 8, 2017):

Hmm, I see, thanks so much @VladimirSchowalter20!

Perhaps I should leave this issue open still as a documentation improvement request?

For example, it's not clear from the website or man pages how these two commands interact with each other.

I.e. it would be great if:

there were examples of them being used together in various ways
if it would be explained how they work when they are both used on the same folder. For example, if I blacklist /foo but also whitelist /foo/bar, what happens? And what happens if I do it the other way around?
Clearly explain on the website which folders can be "whitelisted", what happens with files by default that are neither whitelisted nor blacklisted, etc. etc.

I really liked a paragraph I saw somewhere on the website, something about the authors not believing that security and usability were at odds, but rather they were both essential to each other. This issue, I think, is something where that could better explained / made more usable / clearer, so that users don't accidentally shoot themselves in the foot by assuming something that isn't true.

@taoeffect commented on GitHub (Aug 8, 2017): Hmm, I see, thanks so much @VladimirSchowalter20! Perhaps I should leave this issue open still as a documentation improvement request? For example, it's not clear from the website or man pages how these two commands interact with each other. I.e. it would be great if: - there were examples of them being used together in various ways - if it would be explained how they work when they are both used on the same folder. For example, if I blacklist /foo but also whitelist /foo/bar, what happens? And what happens if I do it the other way around? - Clearly explain on the website which folders can be "whitelisted", what happens with files by default that are neither whitelisted nor blacklisted, etc. etc. I really liked a paragraph I saw somewhere on the website, something about the authors not believing that security and usability were at odds, but rather they were both essential to each other. This issue, I think, is something where that could better explained / made more usable / clearer, so that users don't accidentally shoot themselves in the foot by assuming something that isn't true.

gitea-mirror commented

2026-05-05 07:14:50 -06:00

Author

Owner

@ghost commented on GitHub (Aug 9, 2017):

Yeah, it would be nice to have wiki here on github with detailed explanations with examples but it's a lot of work someone would need to do.

@ghost commented on GitHub (Aug 9, 2017): Yeah, it would be nice to have wiki here on github with detailed explanations with examples but it's a lot of work someone would need to do.

gitea-mirror commented

2026-05-05 07:14:52 -06:00

Author

Owner

@h1z1 commented on GitHub (Aug 19, 2017):

@taoeffect : White and black lists are not by default mutually exclusive and can coexist .. even in infosec. You can have mutually exclusive or inheritance and the priority varies by application. Typically in security the default policy should be deny all for example but isn't guaranteed.

A more open, public facing mail server for example may accept all but which is denied whereas a private one would deny all first, thus whitelist-only. There may even be an implicit policy.

Nothing is perfect though, Firejail cannot ensure drop/deny all. Classic example is X and DBUS or firefox using shared memory between instances. It looks like your browser is isolated until you bring up a file list. Firejail's default policies are a weee too lax for me. I'd much rather have deny and yes crashing is OK, vs the current maintaining and excluding profiles for everything. Most of which I don't have anyway. Glad the option is there though :)

@h1z1 commented on GitHub (Aug 19, 2017): @taoeffect : White and black lists are not by default mutually exclusive and can coexist .. even in infosec. You can have mutually exclusive or inheritance and the priority varies by application. Typically in security the default policy should be deny all for example but isn't guaranteed. A more open, public facing mail server for example may accept all but which is denied whereas a private one would deny all first, thus whitelist-only. There may even be an implicit policy. Nothing is perfect though, Firejail cannot ensure drop/deny all. Classic example is X and DBUS or firefox using shared memory between instances. It looks like your browser is isolated until you bring up a file list. Firejail's default policies are a weee too lax for me. I'd much rather have deny and yes crashing is OK, vs the current maintaining and excluding profiles for everything. Most of which I don't have anyway. Glad the option is there though :)

gitea-mirror commented

2026-05-05 07:14:54 -06:00

Author

Owner

@netblue30 commented on GitHub (Sep 2, 2017):

I'll put in some more documentation, thanks.

@netblue30 commented on GitHub (Sep 2, 2017): I'll put in some more documentation, thanks.

Rows
Columns

[GH-ISSUE #1441] Whitelist isn't really a whitelist...? #975