[GH-ISSUE #5] Whitelist /media directory

gitea-mirror commented

2026-05-05 04:42:42 -06:00

Owner

Originally created by @boltronics on GitHub (Aug 9, 2015).
Original GitHub issue: https://github.com/netblue30/firejail/issues/5

Currently, it is possible to create a filesystem blacklist:

blacklist /etc/shadow*

However, we cannot create a whitelist in the same way. It would be useful to support both blacklist and whitelist options in the same profile.

Use case:
Often it's easier (and safer, in the event of filesystem changes) to just specify one or two files in a directory you want to grant access to. eg.

blacklist /etc
whitelist /etc/fstab
whitelist /etc/hostname
whitelist /etc/issue
whitelist /etc/localtime
whitelist /etc/mailcap
whitelist /etc/nsswitch.conf
whitelist /etc/passwd
whitelist /etc/resolv.conf

Originally created by @boltronics on GitHub (Aug 9, 2015). Original GitHub issue: https://github.com/netblue30/firejail/issues/5 Currently, it is possible to create a filesystem blacklist: ``` blacklist /etc/shadow* ``` However, we cannot create a whitelist in the same way. It would be useful to support both blacklist and whitelist options in the same profile. Use case: Often it's easier (and safer, in the event of filesystem changes) to just specify one or two files in a directory you want to grant access to. eg. ``` blacklist /etc whitelist /etc/fstab whitelist /etc/hostname whitelist /etc/issue whitelist /etc/localtime whitelist /etc/mailcap whitelist /etc/nsswitch.conf whitelist /etc/passwd whitelist /etc/resolv.conf ```

gitea-mirror

2026-05-05 04:42:42 -06:00

closed this issue
added the
information_old
label

gitea-mirror commented

2026-05-05 04:42:50 -06:00

Author

Owner

@netblue30 commented on GitHub (Aug 10, 2015):

This is by far the most requested feature. The problem is once "blacklist /etc" is executed, the directory disappears and "whiltelist /etc/fstab" will not find /etc/fstab.

I did something similar to whitelist for home directory in --private.keep option. The man description is as follows:

   --private.keep=file,directory
          Build a new user home in a temporary filesystem,  and  copy  the
          files and directories in the list in the new home. All modifica‐
          tions are discarded when the sandbox is closed.

          Example:
          $ firejail --private.keep=.mozilla firefox

I'll do the same for /etc directory in a new option --etc.keep. In the profile file it will look like:

         etc.keep fstab,hostname,issue,localtime,mailcap,nsswitch.conf,passwd,resolv.conf

@netblue30 commented on GitHub (Aug 10, 2015): This is by far the most requested feature. The problem is once "blacklist /etc" is executed, the directory disappears and "whiltelist /etc/fstab" will not find /etc/fstab. I did something similar to whitelist for home directory in --private.keep option. The man description is as follows: ``` --private.keep=file,directory Build a new user home in a temporary filesystem, and copy the files and directories in the list in the new home. All modifica‐ tions are discarded when the sandbox is closed. Example: $ firejail --private.keep=.mozilla firefox ``` I'll do the same for /etc directory in a new option --etc.keep. In the profile file it will look like: ``` etc.keep fstab,hostname,issue,localtime,mailcap,nsswitch.conf,passwd,resolv.conf ```

gitea-mirror commented

2026-05-05 04:42:54 -06:00

Author

Owner

@boltronics commented on GitHub (Aug 10, 2015):

Hmm... I understand. Would it be possible then to not have the modifications discarded?

So for example, if I wanted to run Iceweasel but only grant access to ${HOME}/.mozilla, ${HOME}/Downloads and nothing else. I could use the --private.keep=..., but then it sounds like my bookmarks and downloads would disappear.

I realise this gets a bit messy when we have multiple applications wanting .mozilla access... I'm not sure of a good solution to deal with that. Maybe recursively creating hard links for anything specified by --private.keep would work?

@boltronics commented on GitHub (Aug 10, 2015): Hmm... I understand. Would it be possible then to not have the modifications discarded? So for example, if I wanted to run Iceweasel but only grant access to ${HOME}/.mozilla, ${HOME}/Downloads and nothing else. I could use the --private.keep=..., but then it sounds like my bookmarks and downloads would disappear. I realise this gets a bit messy when we have multiple applications wanting .mozilla access... I'm not sure of a good solution to deal with that. Maybe recursively creating hard links for anything specified by --private.keep would work?

gitea-mirror commented

2026-05-05 04:42:57 -06:00

Author

Owner

@ghost commented on GitHub (Aug 12, 2015):

@boltronics For Iceweasel/Firefox I just create a "firefox" directory in $HOME, then start firejail with the "--private=firefox" option. That way the browser has its own private home directory that other apps can see too. Downloads go to ~/firefox/Downloads and can be seen from outside firejail.

@ghost commented on GitHub (Aug 12, 2015): @boltronics For Iceweasel/Firefox I just create a "firefox" directory in $HOME, then start firejail with the "--private=firefox" option. That way the browser has its own private home directory that other apps can see too. Downloads go to ~/firefox/Downloads and can be seen from outside firejail.

gitea-mirror commented

2026-05-05 04:42:59 -06:00

Author

Owner

@boltronics commented on GitHub (Aug 12, 2015):

@pmillerchip Thanks for the tip; that actually works pretty well.

The only nitpick I have there is that the private argument/profile option does not create the directory automatically if it does not already exist. That means I can't just update all my firejail profiles with with the private option, commit to git and deploy everywhere - I need to keep track of a set of basically empty directories everywhere as well, or (more likely) create and commit a script to create them where required.

But this approach is certainly an improvement and gets me most of where I want to be - provided the things I want to blacklist are all under ${HOME}.

@boltronics commented on GitHub (Aug 12, 2015): @pmillerchip Thanks for the tip; that actually works pretty well. The only nitpick I have there is that the `private` argument/profile option does not create the directory automatically if it does not already exist. That means I can't just update all my firejail profiles with with the private option, commit to git and deploy everywhere - I need to keep track of a set of basically empty directories everywhere as well, or (more likely) create and commit a script to create them where required. But this approach is certainly an improvement and gets me most of where I want to be - provided the things I want to blacklist are all under ${HOME}.

gitea-mirror commented

2026-05-05 04:43:02 -06:00

Author

Owner

@ghost commented on GitHub (Aug 12, 2015):

@boltronics Creating the directory is certainly possible, but I don't want to write that myself and submit a pull request because I'd be wary of introducing security holes. We'd have a SUID binary creating things in the filesystem on behalf of an unprivileged user using a path they supplied, so you'd have to be extremely careful writing that code. Personally I like the way firejail works at the moment, where if any tiny thing is wrong it exits immediately. As it's SUID root it makes me feel more comfortable.

@ghost commented on GitHub (Aug 12, 2015): @boltronics Creating the directory is certainly possible, but I don't want to write that myself and submit a pull request because I'd be wary of introducing security holes. We'd have a SUID binary creating things in the filesystem on behalf of an unprivileged user using a path they supplied, so you'd have to be extremely careful writing that code. Personally I like the way firejail works at the moment, where if any tiny thing is wrong it exits immediately. As it's SUID root it makes me feel more comfortable.

gitea-mirror commented

2026-05-05 04:43:04 -06:00

Author

Owner

@boltronics commented on GitHub (Aug 12, 2015):

@pmillerchip That's a really good point.

With that in mind, why do we have firejail set to be SUID directly? If we look at Chromium (for example), /usr/bin/chromium is not SUID, but rather it calls /usr/lib/chromium/chrome-sandbox for just the part of the execution where it's strictly required. For example, I can delete that file, and chromium --version still works as expected.

It seems firejail would probably benefit from a similar setup (and we already have a couple of executable files under /usr/lib/firejail too). I imagine that would alleviate such concerns?

There's probably a fair bit of code running SUID already that isn't strictly necessary, such as (I imagine) the config parser stuff.

@boltronics commented on GitHub (Aug 12, 2015): @pmillerchip That's a really good point. With that in mind, why do we have firejail set to be SUID directly? If we look at Chromium (for example), `/usr/bin/chromium` is not SUID, but rather it calls `/usr/lib/chromium/chrome-sandbox` for just the part of the execution where it's strictly required. For example, I can delete that file, and `chromium --version` still works as expected. It seems firejail would probably benefit from a similar setup (and we already have a couple of executable files under `/usr/lib/firejail` too). I imagine that would alleviate such concerns? There's probably a fair bit of code running SUID already that isn't strictly necessary, such as (I imagine) the config parser stuff.

gitea-mirror commented

2026-05-05 04:43:06 -06:00

Author

Owner

@ghost commented on GitHub (Aug 12, 2015):

@boltronics I did some looking, it seems firejail already performs some copying in the "--private.keep" option. It forks a child process which drops all privileges and performs the copy. As there's already code for this, it could be adapted to set up the private home directory in the same way for the "--private=dir" option.

Restructuring firejail with a separate SUID part is a nice idea, but I fear it would be a lot of work for poor netblue30!

@ghost commented on GitHub (Aug 12, 2015): @boltronics I did some looking, it seems firejail already performs some copying in the "--private.keep" option. It forks a child process which drops all privileges and performs the copy. As there's already code for this, it could be adapted to set up the private home directory in the same way for the "--private=dir" option. Restructuring firejail with a separate SUID part is a nice idea, but I fear it would be a lot of work for poor netblue30!

gitea-mirror commented

2026-05-05 04:43:08 -06:00

Author

Owner

@netblue30 commented on GitHub (Aug 12, 2015):

pmillerchip is right, I'm asking for trouble creating new directories.

I ended up implementing a --private-etc option as follows:

  --private-etc=file,directory
          Build  a  new /etc in a temporary filesystem, and copy the files
          and directories in the list.  All  modifications  are  discarded
          when the sandbox is closed.

          Example:
          $ firejail --private-etc=group,hostname,localtime, \
          nsswitch.conf,passwd,resolv.conf

(similar for profiles)

@netblue30 commented on GitHub (Aug 12, 2015): pmillerchip is right, I'm asking for trouble creating new directories. I ended up implementing a --private-etc option as follows: ``` --private-etc=file,directory Build a new /etc in a temporary filesystem, and copy the files and directories in the list. All modifications are discarded when the sandbox is closed. Example: $ firejail --private-etc=group,hostname,localtime, \ nsswitch.conf,passwd,resolv.conf ``` (similar for profiles)

gitea-mirror commented

2026-05-05 04:43:10 -06:00

Author

Owner

@boltronics commented on GitHub (Aug 12, 2015):

Thanks netblue30!

@boltronics commented on GitHub (Aug 12, 2015): Thanks netblue30!

gitea-mirror commented

2026-05-05 04:43:12 -06:00

Author

Owner

@netblue30 commented on GitHub (Aug 12, 2015):

No problem, I'll close the bug for now.

@netblue30 commented on GitHub (Aug 12, 2015): No problem, I'll close the bug for now.

gitea-mirror commented

2026-05-05 04:43:13 -06:00

Author

Owner

@ghost commented on GitHub (Oct 26, 2015):

Bringing this issue back up.

I have Steam games stored on another drive. I'd like for Steam to be able to access those, but not to any other folders on that drive.

E.g. something like:

blacklist /media
whitelist /media/*user*/*drive*/Steam

Perhaps there could be a more generic --keep flag?

@ghost commented on GitHub (Oct 26, 2015): Bringing this issue back up. I have Steam games stored on another drive. I'd like for Steam to be able to access those, but not to any other folders on that drive. E.g. something like: ``` blacklist /media whitelist /media/*user*/*drive*/Steam ``` Perhaps there could be a more generic --keep flag?

gitea-mirror commented

2026-05-05 04:43:15 -06:00

Author

Owner

@netblue30 commented on GitHub (Oct 26, 2015):

I think I can build some sort of whitelisting for /media.

@netblue30 commented on GitHub (Oct 26, 2015): I think I can build some sort of whitelisting for /media.

gitea-mirror commented

2026-05-05 04:43:16 -06:00

Author

Owner

@ghost commented on GitHub (Oct 26, 2015):

Well on Ubuntu it's /media/user/disk. On Fedora it's /var/run/user/disk.

You can see where this starts getting a big complex.

@ghost commented on GitHub (Oct 26, 2015): Well on Ubuntu it's /media/user/disk. On Fedora it's /var/run/user/disk. You can see where this starts getting a big complex.

gitea-mirror commented

2026-05-05 04:43:19 -06:00

Author

Owner

@netblue30 commented on GitHub (Oct 27, 2015):

It is all over the place. In Debian wheezy is on /media.

The number of entries in /media is small. Blacklist whatever you don't need for now.

@netblue30 commented on GitHub (Oct 27, 2015): It is all over the place. In Debian wheezy is on /media. The number of entries in /media is small. Blacklist whatever you don't need for now.

gitea-mirror commented

2026-05-05 04:43:21 -06:00

Author

Owner

@netblue30 commented on GitHub (Nov 15, 2015):

Implemented!

Whitelist command now accepts user home, /dev, /media, /var, and /tmp directories.

@netblue30 commented on GitHub (Nov 15, 2015): Implemented! Whitelist command now accepts user home, /dev, /media, /var, and /tmp directories.

gitea-mirror commented

2026-05-05 04:43:23 -06:00

Author

Owner

@SkewedZeppelin commented on GitHub (Sep 13, 2016):

@netblue30 could you please make whitelist also accept /mnt? or a config option to disable that check? Thanks.

@SkewedZeppelin commented on GitHub (Sep 13, 2016): @netblue30 could you please make whitelist also accept /mnt? or a config option to disable that check? Thanks.

gitea-mirror commented

2026-05-05 04:43:25 -06:00

Author

Owner

@netblue30 commented on GitHub (Sep 15, 2016):

I'll add support for it, moved here: https://github.com/netblue30/firejail/issues/781

@netblue30 commented on GitHub (Sep 15, 2016): I'll add support for it, moved here: https://github.com/netblue30/firejail/issues/781

gitea-mirror commented

2026-05-05 04:43:28 -06:00

Author

Owner

@g4jc commented on GitHub (Nov 24, 2016):

I've found a possible solution to this problem, but for unknown reasons firejail fights it's own permissions and shuts down.

Examine the following:

/usr/bin/firejail --noprofile --seccomp --netfilter --nonewprivs --noroot --nogroups $(find /home -maxdepth 2 -type f -not -name ".Xauthority" -not -name ".icedove" -not -name ".gnupg" | awk 1 ORS=' --blacklist=' | rev | cut -c 14- | rev ) --caps.drop=all --private-etc=/etc --private-bin=gpg2 --private-tmp /usr/lib/icedove/icedove

What this one-liner does is nest a find command in firejail startup which creates a properly parsed "--blacklist" for everything in everyone's home folder. It also creates a whitelist via find's "not-name" command - Then it runs the program.

The problem with this method is files in your home directory will randomly fail and the script gets stuck.

Parent pid 21911, child pid 21912 Child process initialized /bin/bash: /home/user/readme.[2015-01-20].txt: Permission denied Parent is shutting down, bye...

I am unsure if this is a race condition or if firejail is blocking files prior to running --black-list.

@g4jc commented on GitHub (Nov 24, 2016): I've found a possible solution to this problem, but for unknown reasons firejail fights it's own permissions and shuts down. Examine the following: `/usr/bin/firejail --noprofile --seccomp --netfilter --nonewprivs --noroot --nogroups $(find /home -maxdepth 2 -type f -not -name ".Xauthority" -not -name ".icedove" -not -name ".gnupg" | awk 1 ORS=' --blacklist=' | rev | cut -c 14- | rev ) --caps.drop=all --private-etc=/etc --private-bin=gpg2 --private-tmp /usr/lib/icedove/icedove` What this one-liner does is nest a find command in firejail startup which creates a properly parsed "--blacklist" for everything in everyone's home folder. It also creates a whitelist via find's "not-name" command - Then it runs the program. The problem with this method is files in your home directory will randomly fail and the script gets stuck. `Parent pid 21911, child pid 21912 Child process initialized /bin/bash: /home/user/readme.[2015-01-20].txt: Permission denied Parent is shutting down, bye...` I am unsure if this is a race condition or if firejail is blocking files prior to running --black-list.

gitea-mirror commented

2026-05-05 04:43:30 -06:00

Author

Owner

@netblue30 commented on GitHub (Nov 27, 2016):

I'll look into it, thanks.

@netblue30 commented on GitHub (Nov 27, 2016): I'll look into it, thanks.

gitea-mirror referenced this issue

2026-05-05 05:06:26 -06:00

[GH-ISSUE #175] using links in sandboxed firefox #121

Rows
Columns

[GH-ISSUE #5] Whitelist /media directory #6