[GH-ISSUE #2969] whitelist/blacklist nesting + private-bin

gitea-mirror commented

2026-05-05 08:31:36 -06:00

Owner

Originally created by @blinux45 on GitHub (Sep 17, 2019).
Original GitHub issue: https://github.com/netblue30/firejail/issues/2969

This issue is somewhat similar to:
https://github.com/netblue30/firejail/issues/2882

I cannot figure out the whitelist/blacklist priorities within firejail.

If I set:
whitelist /bin/bash
noblacklist /bin/bash
blacklist /bin
I get: Error invalid whitelist path /bin/bash
No matter how I order my whitelists/blacklist, I do not seem to be able to whitelist a subdirectory or a single file within a blacklisted directory.

On a slightly different try, if I set:
private-bin bash,ls,cat,ping,iptables
When I run ping w.x.y.z, I get
ping: socket: Operation not permitted

With ls -l /bin
I get
-rwxr-xr-x-r l root 0 68976 ping
The suid for ping is set to 'x' and not to 's'
Not sure how to remedy that once inside firejail.

Originally created by @blinux45 on GitHub (Sep 17, 2019). Original GitHub issue: https://github.com/netblue30/firejail/issues/2969 This issue is somewhat similar to: https://github.com/netblue30/firejail/issues/2882 I cannot figure out the whitelist/blacklist priorities within firejail. If I set: whitelist /bin/bash noblacklist /bin/bash blacklist /bin I get: Error invalid whitelist path /bin/bash No matter how I order my whitelists/blacklist, I do not seem to be able to whitelist a subdirectory or a single file within a blacklisted directory. On a slightly different try, if I set: private-bin bash,ls,cat,ping,iptables When I run ping w.x.y.z, I get ping: socket: Operation not permitted With ls -l /bin I get -rwxr-xr-x-r l root 0 68976 ping The suid for ping is set to 'x' and not to 's' Not sure how to remedy that once inside firejail.

gitea-mirror

2026-05-05 08:31:36 -06:00

closed this issue
added the
bug

question_old
labels

gitea-mirror commented

2026-05-05 08:31:39 -06:00

Author

Owner

@smitsohu commented on GitHub (Sep 17, 2019):

whitelist /bin/bash
I get: Error invalid whitelist path /bin/bash

This is because whitelisting in /bin is unsupported currently. Quoting the man page:

The top directory could be user home, /dev, /etc, /media, /mnt, /opt, /run/user/$UID, /srv, /sys/module, /tmp, /usr/share and /var

Your other observation is interesting:

private-bin bash,ls,cat,ping,iptables
With ls -l /bin
I get
-rwxr-xr-x-r l root 0 68976 ping
The suid for ping is set to 'x' and not to 's'

That doesn't work, indeed. It's probably because we mount /bin with a nosuid flag inside the sandbox. Should this stay or should we fix it? @netblue30 and others

@smitsohu commented on GitHub (Sep 17, 2019): > whitelist /bin/bash > I get: Error invalid whitelist path /bin/bash This is because whitelisting in /bin is unsupported currently. Quoting the man page: > The top directory could be user home, /dev, /etc, /media, /mnt, /opt, /run/user/$UID, /srv, /sys/module, /tmp, /usr/share and /var Your other observation is interesting: > private-bin bash,ls,cat,ping,iptables > With ls -l /bin > I get > -rwxr-xr-x-r l root 0 68976 ping > The suid for ping is set to 'x' and not to 's' That doesn't work, indeed. It's probably because we mount /bin with a `nosuid` flag inside the sandbox. Should this stay or should we fix it? @netblue30 and others

gitea-mirror commented

2026-05-05 08:31:40 -06:00

Author

Owner

@FOSSONLY commented on GitHub (Sep 17, 2019):

I think you should keep "nosuid", especially since you can also work with capabilities. Strictly speaking "ping" only needs "cap_net_raw", and no suid bit or full root rights. This is practiced under Debian, for example, so that "ping" can be used entirely with user rights. Due to the potential danger, suid binaries should be consistently defused or eliminated.

@FOSSONLY commented on GitHub (Sep 17, 2019): I think you should keep "nosuid", especially since you can also work with capabilities. Strictly speaking "ping" only needs "cap_net_raw", and no suid bit or full root rights. This is practiced under Debian, for example, so that "ping" can be used entirely with user rights. Due to the potential danger, suid binaries should be consistently defused or eliminated.

gitea-mirror commented

2026-05-05 08:31:42 -06:00

Author

Owner

@blinux45 commented on GitHub (Sep 18, 2019):

Thank you for the responses.
Some additional test:

First, using /home, a "supported directory":

TEST #1
whitelist /home/topdir/subdir
noblacklist /home/topdir/subdir
blacklist /home
ls: cannot access '/home/topdir/subdir' : Permission denied

TEST #2
whitelist /home/topdir/subdir
noblacklist /home/topdir/subdir
blacklist /home/topdir
ls -l /home
Only /home/myuser is listed.
topdir is not listed and subdir not accessible
ls -l /home/topdir/subdir
ls: cannot access '/home/topdir/subdir' : No such file or directory

In the two examples above, the whitelisting of /home/topdir/subdir is ignored by firejail.

TEST #3
Since the directory 'myuser' seems to exists, let's test if we can blacklist the content of /myuser (somewhat equivalent to private directory) with the exception of one subfolder '/myuser/firejail'.

whitelist /home/myuser/firejail
noblacklist /home/myuser/firejail
blacklist /home/myuser
cd /home/myuser
bash: cd: myuser: Permission denied
cd /home/myuser/firejail
bash: cd: myuser/firejail: Permission denied

TEST #4
Outside firejail:
$ mkdir /home/myuser/firejail
$ cp /bin/ping /home/myuser/firejail
$ chmod 4755 /home/myuser/firejail/ping
Inside firejail:
$ ls -l ~/firejail
total 68 <== Not sure where '68' is coming from, there is only one file.
-rwsr-xr-x 1 root 0 68076 Sep 18 13:02 ping <== The suid is set correctly
$ ~/firejail/ping -c1 w.x.y.z
ping: socket: Operation not permitted
Ping has the right suid but it is still not working; and capabilities have not been modified.

@blinux45 commented on GitHub (Sep 18, 2019): Thank you for the responses. Some additional test: First, using /home, a "supported directory": TEST #1 whitelist /home/topdir/subdir noblacklist /home/topdir/subdir blacklist /home ls: cannot access '/home/topdir/subdir' : Permission denied TEST #2 whitelist /home/topdir/subdir noblacklist /home/topdir/subdir blacklist /home/topdir ls -l /home Only /home/myuser is listed. topdir is not listed and subdir not accessible ls -l /home/topdir/subdir ls: cannot access '/home/topdir/subdir' : No such file or directory In the two examples above, the whitelisting of /home/topdir/subdir is ignored by firejail. TEST #3 Since the directory 'myuser' seems to exists, let's test if we can blacklist the content of /myuser (somewhat equivalent to private directory) with the exception of one subfolder '/myuser/firejail'. whitelist /home/myuser/firejail noblacklist /home/myuser/firejail blacklist /home/myuser cd /home/myuser bash: cd: myuser: Permission denied cd /home/myuser/firejail bash: cd: myuser/firejail: Permission denied TEST #4 Outside firejail: $ mkdir /home/myuser/firejail $ cp /bin/ping /home/myuser/firejail $ chmod 4755 /home/myuser/firejail/ping Inside firejail: $ ls -l ~/firejail total 68 <== Not sure where '68' is coming from, there is only one file. -rwsr-xr-x 1 root 0 68076 Sep 18 13:02 ping <== The suid is set correctly $ ~/firejail/ping -c1 w.x.y.z ping: socket: Operation not permitted Ping has the right suid but it is still not working; and capabilities have not been modified.

gitea-mirror commented

2026-05-05 08:31:44 -06:00

Author

Owner

@rusty-snake commented on GitHub (Sep 18, 2019):

More infos: https://github.com/netblue30/firejail/wiki/Creating-Profiles#common-mistakes

This is expected because you have blacklist /home. how should your noblacklist work? forbid access to /home but allow something in /home? that doesn't work

In the two examples above, the whitelisting of /home/topdir/subdir is ignored by firejail.

Nope, but whitelist doesn't mean allow access to this file, it means forbid everything except what is whitelisted.

To summary you can blacklist a file (or dir) which mean access is denied, you can ignore a blacklist with noblacklist but if you deny access to one dir, you can't touch files with in this dir. Alternative you can hide files with whitelist. whitelist ${HOME}/.bashrc means that over your HOME-dir is a new tmpfs mounted, and every whitelisted file in bind mounted inside this new HOME.
Confirming. #2970.

@rusty-snake commented on GitHub (Sep 18, 2019): More infos: https://github.com/netblue30/firejail/wiki/Creating-Profiles#common-mistakes 1. This is expected because you have `blacklist /home`. how should your noblacklist work? forbid access to /home but allow something in /home? that doesn't work 2. > In the two examples above, the whitelisting of /home/topdir/subdir is ignored by firejail. Nope, but `whitelist` doesn't mean allow access to this file, it means forbid everything except what is whitelisted. 3. To summary you can `blacklist` a file (or dir) which mean access is denied, you can ignore a blacklist with `noblacklist` but if you deny access to one dir, you can't touch files with in this dir. Alternative you can hide files with `whitelist`. `whitelist ${HOME}/.bashrc` means that over your HOME-dir is a new tmpfs mounted, and every `whitelist`ed file in bind mounted inside this new HOME. 4. Confirming. #2970.

gitea-mirror commented

2026-05-05 08:31:44 -06:00

Author

Owner

@blinux45 commented on GitHub (Sep 19, 2019):

Thank you very much rusty-snake:
I resolved the blacklisting/whitelisting of directories and subdirectories.
The key was understanding what "whitelist" means.
QUOTE:
whitelist doesn't mean allow access to this file, it means forbid EVERYTHING except what is whitelisted.

This is different from the customary meaning and for this reason counterintuitive. I had read the man page, but it did not register. Old habits die hard and may I suggest adding a clarification to the man page. I don't think I will be the only one to be confused by this.

Regarding the ping issue, uncommenting force-nonewprivs no in /etc/firejail/firejail.config did not resolve it.

@blinux45 commented on GitHub (Sep 19, 2019): Thank you very much rusty-snake: I resolved the blacklisting/whitelisting of directories and subdirectories. The key was understanding what "whitelist" means. QUOTE: `whitelist` doesn't mean allow access to this file, it means forbid EVERYTHING except what is whitelisted. This is different from the customary meaning and for this reason counterintuitive. I had read the man page, but it did not register. Old habits die hard and may I suggest adding a clarification to the man page. I don't think I will be the only one to be confused by this. Regarding the ping issue, uncommenting `force-nonewprivs no` in /etc/firejail/firejail.config did not resolve it.

gitea-mirror commented

2026-05-05 08:31:45 -06:00

Author

Owner

@rusty-snake commented on GitHub (Sep 19, 2019):

I don't think I will be the only one to be confused by this.

Are you not the only one, there are several issues like this. If you write or customize profiles then IMHO this the biggest barrier at the moment.

Regarding the ping issue, uncommenting force-nonewprivs no in /etc/firejail/firejail.config did not resolve it.

I would like to clarify that for me ping worked within firejail until I used "private-bin ping,....".

I had overlooked this, sorry. As @smitsohu say /bin is mounted nosuid.

@rusty-snake commented on GitHub (Sep 19, 2019): > I don't think I will be the only one to be confused by this. Are you not the only one, there are several issues like this. If you write or customize profiles then IMHO this the biggest barrier at the moment. > Regarding the ping issue, uncommenting force-nonewprivs no in /etc/firejail/firejail.config did not resolve it. > I would like to clarify that for me ping worked within firejail until I used "private-bin ping,....". I had overlooked this, sorry. As @smitsohu say /bin is mounted `nosuid`.

gitea-mirror commented

2026-05-05 08:31:45 -06:00

Author

Owner

@smitsohu commented on GitHub (Sep 20, 2019):

@FOSSONLY I understand where you are coming from, but as Firejail in general allows running suid programs, and a user can choose freely among all the options, there is probably not much to gain from a nosuid /bin (/usr/bin and so on).

On a per-sandbox base, we actually don't need private-bin to prevent suid programs from running. There are other options like nonewprivs and caps.drop all, also everything related to seccomp, and crucially all of this is opt-in. In case we don't want Firejail to run code with elevated privileges at all, then the proper way is to enable the force-nonewprivs switch in firejail.config (as @rusty-snake did).

With that said, a nosuid mounted /bin (/usr/bin and so on) looks to me more like a bug than a feature.

@smitsohu commented on GitHub (Sep 20, 2019): @FOSSONLY I understand where you are coming from, but as Firejail in general allows running suid programs, and a user can choose freely among all the options, there is probably not much to gain from a `nosuid` /bin (/usr/bin and so on). On a per-sandbox base, we actually don't need `private-bin` to prevent suid programs from running. There are other options like `nonewprivs` and `caps.drop all`, also everything related to seccomp, and crucially all of this is _opt-in_. In case we don't want Firejail to run code with elevated privileges _at all_, then the proper way is to enable the `force-nonewprivs` switch in firejail.config (as @rusty-snake did). With that said, a nosuid mounted /bin (/usr/bin and so on) looks to me more like a bug than a feature.

gitea-mirror commented

2026-05-05 08:31:46 -06:00

Author

Owner

@sitaramc commented on GitHub (Nov 12, 2019):

This is because whitelisting in /bin is unsupported currently. Quoting the man page:

The top directory could be user home, /dev, /etc, /media, /mnt, /opt, /run/user/$UID, /srv, /sys/module, /tmp, /usr/share and /var

Just FYI, I managed to work around this, though my interest was in a "/extra" partition that contained several documents, and I wanted to make sure that when I opened one of them, libreoffice or zathura or whatever I used could not even see any of the others.

Here's what I did. It's a bit kludgey, and the root step has to be repeated every boot after logging in, but it seems to work.

mkdir /extra/view from the logged in user (one time)
mkdir /run/user/1001/view; mount --bind /extra/view /run/user/1001/view from root (every boot)

Viewing the files is done by a script that

hard links the file from wherever it is in /extra, to /extra/view
runs cd /run/user/1001/view; firejail [other options] --whitelist=$PWD zathura $FILE, where $FILE is the basename of the file that was hard linked

There's also some cleanup involved, which I have not yet looked at (the file stays there forever, visible to later sessions, though because of the hard link it is not taking up extra space).

Am new(-ish) to firejail, at least for anything more than the defaults, so it would be nice if someone could comment on this. Basically I got around the limits of --whitelist and managed to make it whitelist a single file in some other (unsupported) top dir.

@sitaramc commented on GitHub (Nov 12, 2019): > > > > This is because whitelisting in /bin is unsupported currently. Quoting the man page: > > > The top directory could be user home, /dev, /etc, /media, /mnt, /opt, /run/user/$UID, /srv, /sys/module, /tmp, /usr/share and /var Just FYI, I managed to work around this, though my interest was in a "/extra" partition that contained several documents, and I wanted to make sure that when I opened one of them, libreoffice or zathura or whatever I used could not even *see* any of the others. Here's what I did. It's a bit kludgey, and the root step has to be repeated every boot *after* logging in, but it seems to work. - `mkdir /extra/view` from the logged in user (one time) - `mkdir /run/user/1001/view; mount --bind /extra/view /run/user/1001/view` from root (every boot) Viewing the files is done by a script that - hard links the file from wherever it is in /extra, to /extra/view - runs `cd /run/user/1001/view; firejail [other options] --whitelist=$PWD zathura $FILE`, where $FILE is the basename of the file that was hard linked There's also some cleanup involved, which I have not yet looked at (the file stays there forever, visible to later sessions, though because of the hard link it is not taking up extra space). Am new(-ish) to firejail, at least for anything more than the defaults, so it would be nice if someone could comment on this. Basically I got around the limits of `--whitelist` and managed to make it whitelist a single file in some other (unsupported) top dir.

gitea-mirror commented

2026-05-05 08:31:46 -06:00

Author

Owner

@smitsohu commented on GitHub (Nov 12, 2019):

@sitaramc Yes, it is perfectly fine to work around the whitelist limitation with bind-mounting. I only wonder if you could just bind-mount the entire /extra to a place where whitelisting is possible, avoiding the linking step.

And don't forget to also blacklist the original /extra directory in order to not expose your data there.

@smitsohu commented on GitHub (Nov 12, 2019): @sitaramc Yes, it is perfectly fine to work around the whitelist limitation with bind-mounting. I only wonder if you could just bind-mount the entire /extra to a place where whitelisting is possible, avoiding the linking step. And don't forget to also blacklist the original /extra directory in order to not expose your data there.

gitea-mirror commented

2026-05-05 08:31:46 -06:00

Author

Owner

@rusty-snake commented on GitHub (Nov 12, 2019):

mkdir /run/user/1001/view; mount --bind /extra/view /run/user/1001/view from root (every boot)

You can bind mount from fstab. IDK if RUNUSER already exists when the mounts are performed, but you can use a systemd-unit if not.

@rusty-snake commented on GitHub (Nov 12, 2019): > `mkdir /run/user/1001/view; mount --bind /extra/view /run/user/1001/view` from root (every boot) You can bind mount from fstab. IDK if RUNUSER already exists when the mounts are performed, but you can use a systemd-unit if not.

gitea-mirror commented

2026-05-05 08:31:47 -06:00

Author

Owner

@sitaramc commented on GitHub (Nov 13, 2019):

On Tue, Nov 12, 2019 at 05:49:20AM -0800, smitsohu wrote:

Yes, it is perfectly fine to work around the limitation with bind-mounting. I only wonder if you could just bind-mount the entire /extra to a place where whitelisting is possible, avoiding the linking step.

I'll have to try that; thanks

And don't forget to also blacklist the original /extra directory in order to not expose your data there.

oh yes I forgot to mention that I'd already done this (long
ago), forgetting that I might occasionally need to access those
old files.

@sitaramc commented on GitHub (Nov 13, 2019): On Tue, Nov 12, 2019 at 05:49:20AM -0800, smitsohu wrote: > Yes, it is perfectly fine to work around the limitation with bind-mounting. I only wonder if you could just bind-mount the entire /extra to a place where whitelisting is possible, avoiding the linking step. I'll have to try that; thanks > And don't forget to also blacklist the original /extra directory in order to not expose your data there. oh yes I forgot to mention that I'd already done this (long ago), forgetting that I might occasionally need to access those old files.

gitea-mirror commented

2026-05-05 08:31:47 -06:00

Author

Owner

@rusty-snake commented on GitHub (Jan 17, 2020):

I'm closing here due to inactivity, please fell free to reopen if you have more questions.

@rusty-snake commented on GitHub (Jan 17, 2020): I'm closing here due to inactivity, please fell free to reopen if you have more questions.

Rows
Columns

[GH-ISSUE #2969] whitelist/blacklist nesting + private-bin #1855