Firejail: whitelist/blacklist nesting + private-bin

[blinux45]

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.

[smitsohu]

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

[FOSSONLY]

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.

[blinux45]

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.

[rusty-snake]

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.

1. 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.
2. Confirming. #2970.

[blinux45]

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.

[rusty-snake]

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.

[smitsohu]

@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.

[sitaramc]

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.

[smitsohu]

@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.

[rusty-snake]

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.

[sitaramc]

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.

[rusty-snake]

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