[GH-ISSUE #578] Thought: blacklist all .files and folders by default.

gitea-mirror commented

2026-05-05 05:48:39 -06:00

Owner

Originally created by @Fred-Barclay on GitHub (Jun 17, 2016).
Original GitHub issue: https://github.com/netblue30/firejail/issues/578

We already blacklist most hidden directories and files with disable-common, disable-passwdmgr, and especially disable-programs. Then we noblacklist the files in the appropriate profiles.

This has the weakness of requiring multiple disable.inc files, which can lead to unnecessary duplication, complication, and confusion. It also opens a bit of a security risk in that hidden files that aren't blacklisted are visible to the sandbox. While currently firejail blacklists all the sensitive hidden files, sooner or later there will be one that isn't included in the sandbox that should have been.

Why not just disable them all in a single file? Something like disable-hidden.inc: blacklist ${HOME}/.*.
Then we can just add the necessary noblacklists to the profiles. We do this already since nearly all hidden files are blacklisted already, so most profiles would be ready-to-go as they are right now. A few profiles will have to be modified (esp. if they need .bashrc which is currently visible to the sandbox) but there is plenty of time for debugging before the next firejail release (right, @netblue30 ? 😄)

And on the positive side, a bit of testing in terminal has shown no problems on my side.

Thoughts, mates? My last big change wasn't welcomed by some so I thought I'd get responses before creating a pull request. A rough mental draft is ready to go depending on the feedback.

Originally created by @Fred-Barclay on GitHub (Jun 17, 2016). Original GitHub issue: https://github.com/netblue30/firejail/issues/578 We already blacklist most hidden directories and files with disable-common, disable-passwdmgr, and especially disable-programs. Then we noblacklist the files in the appropriate profiles. This has the weakness of requiring multiple disable.inc files, which can lead to unnecessary duplication, complication, and confusion. It also opens a bit of a security risk in that hidden files that **aren't** blacklisted are visible to the sandbox. While currently firejail blacklists all the sensitive hidden files, sooner or later there will be one that isn't included in the sandbox that should have been. Why not just disable them all in a single file? Something like _disable-hidden.inc_: `blacklist ${HOME}/.*`. Then we can just add the necessary noblacklists to the profiles. We do this already since nearly all hidden files are blacklisted already, so most profiles would be ready-to-go as they are right now. A few profiles will have to be modified (esp. if they need .bashrc which is currently visible to the sandbox) but there is plenty of time for debugging before the next firejail release (right, @netblue30 ? :smile:) And on the positive side, a bit of testing in terminal has shown no problems on my side. Thoughts, mates? My last big change wasn't welcomed by some so I thought I'd get responses before creating a pull request. A rough mental draft is ready to go depending on the feedback.

gitea-mirror

2026-05-05 05:48:39 -06:00

closed this issue
added the
enhancement
label

gitea-mirror commented

2026-05-05 05:48:45 -06:00

Author

Owner

@chiraag-nataraj commented on GitHub (Jun 17, 2016):

Sounds like an improvement in security! 😄

@chiraag-nataraj commented on GitHub (Jun 17, 2016): Sounds like an improvement in security! :smile:

gitea-mirror commented

2026-05-05 05:48:48 -06:00

Author

Owner

@Fred-Barclay commented on GitHub (Jun 18, 2016):

Thanks. That's what I'm hoping. :)

@Fred-Barclay commented on GitHub (Jun 18, 2016): Thanks. That's what I'm hoping. :)

gitea-mirror commented

2026-05-05 05:48:51 -06:00

Author

Owner

@Fred-Barclay commented on GitHub (Jun 18, 2016):

Will probably conflict with #579

@Fred-Barclay commented on GitHub (Jun 18, 2016): Will probably conflict with #579

gitea-mirror commented

2026-05-05 05:48:54 -06:00

Author

Owner

@netblue30 commented on GitHub (Jun 18, 2016):

You guys are worse than a six year old :)

@Fred-Barclay: you are right, all the include system is a mess in this moment. What you propose is also somehow releated to https://github.com/netblue30/firejail/issues/504. Let's leave it open for now, I'll mark it as an enhancement and go for it in the release after the current one.

The thing is I've already started adding private-bin and whitelisting /tmp directory all over the place. Also private-dev and private-etc are in plan. By the time I'm done, everything will be broken. So no messing around with the include files, instead just put in some pull requests with whatever you have in your private profiles. If is working on your setup, it should be fine, and we'll fix it when people start complaining.

@netblue30 commented on GitHub (Jun 18, 2016): You guys are worse than a six year old :) @Fred-Barclay: you are right, all the include system is a mess in this moment. What you propose is also somehow releated to https://github.com/netblue30/firejail/issues/504. Let's leave it open for now, I'll mark it as an enhancement and go for it in the release after the current one. The thing is I've already started adding private-bin and whitelisting /tmp directory all over the place. Also private-dev and private-etc are in plan. By the time I'm done, everything will be broken. So no messing around with the include files, instead just put in some pull requests with whatever you have in your private profiles. If is working on your setup, it should be fine, and we'll fix it when people start complaining.

gitea-mirror commented

2026-05-05 05:48:56 -06:00

Author

Owner

@Fred-Barclay commented on GitHub (Jun 18, 2016):

"You guys are worse than a six year old :)"
I am six and three-quarters! 😉 I'm tellin' my mommy!

Will do. Will the next release be 0.9.41 or 0.9.42? I noticed you seem to use even-numbered point releases.

@Fred-Barclay commented on GitHub (Jun 18, 2016): "You guys are worse than a six year old :)" I am six and three-quarters! :wink: I'm tellin' my mommy! Will do. Will the next release be 0.9.41 or 0.9.42? I noticed you seem to use even-numbered point releases.

gitea-mirror commented

2026-05-05 05:48:57 -06:00

Author

Owner

@netblue30 commented on GitHub (Jun 19, 2016):

0.9.41 is the development tag. It will be released as 0.9.42 once is ready.

@netblue30 commented on GitHub (Jun 19, 2016): 0.9.41 is the development tag. It will be released as 0.9.42 once is ready.

gitea-mirror commented

2026-05-05 05:48:58 -06:00

Author

Owner

@SYN-cook commented on GitHub (Apr 2, 2017):

@Fred-Barclay An alternative implementation of your idea would be to generally switch to whitelisting, and to whitelist all non-hidden directories in the root of user home (like the XDG defaults ~/Videos, ~/Downloads and so on). From a usability perspective the result would be the same, but the approach has the advantage of effectively handling #1011, which is otherwise fairly trivial to exploit.

Take only Gnome: How many installations out there have one the files ~/.gnomerc, ~/.xsessionrc or ~./xprofile in user home, not even talking about all of them? But all these files are sourced on startup, an attacker just needs to create the one that's missing. Blacklisting would not safe you from that, whitelisting will.

But admittedly rewriting all profiles for whitelisting would be a major effort, and having more restrictive profiles also increases the risk of breaking functionality.

@SYN-cook commented on GitHub (Apr 2, 2017): @Fred-Barclay An alternative implementation of your idea would be to generally switch to whitelisting, and to whitelist all non-hidden directories in the root of user home (like the XDG defaults ~/Videos, ~/Downloads and so on). From a usability perspective the result would be the same, but the approach has the advantage of effectively handling #1011, which is otherwise fairly trivial to exploit. Take only Gnome: How many installations out there have one the files `~/.gnomerc`, `~/.xsessionrc` or `~./xprofile` in user home, not even talking about _all_ of them? But [_all_ these files](https://www.debian.org/doc/manuals/debian-reference/ch07.en.html#_starting_the_x_window_system) are sourced on startup, an attacker just needs to create the one that's missing. Blacklisting would not safe you from that, whitelisting will. But admittedly rewriting all profiles for whitelisting would be a major effort, and having more restrictive profiles also increases the risk of breaking functionality.

gitea-mirror commented

2026-05-05 05:49:00 -06:00

Author

Owner

@chiraag-nataraj commented on GitHub (Jul 15, 2018):

@SYN-cook @Fred-Barclay Do you think we've sufficiently cleaned up the profiles to close this or should we keep it open to motivate us further?

@chiraag-nataraj commented on GitHub (Jul 15, 2018): @SYN-cook @Fred-Barclay Do you think we've sufficiently cleaned up the profiles to close this or should we keep it open to motivate us further?

gitea-mirror commented

2026-05-05 05:49:01 -06:00

Author

Owner

@chiraag-nataraj commented on GitHub (Jul 15, 2018):

Also, I would suggest maybe going the route I do in my personal profiles: only use whitelists and keep them within the specific profiles (see my repository for examples of what I mean). I use a common.inc which sets up a bunch of rudimentary blacklists and security options (apparmor,caps.drop,seccomp,etc.) which can be overwritten in a program's profile if necessary (ignore <predicate>). The nice thing about this approach is that everything in common.inc is truly common - it should be true by default in every profile (and only disabled if the program doesn't work with it enabled). And since all of the profiles have whitelists for files and directories in ~ (except for maybe one or two, which I'm working on), it's not at all an issue that common.inc doesn't have any blacklists or whitelists of those files.

@chiraag-nataraj commented on GitHub (Jul 15, 2018): Also, I would suggest maybe going the route I do in my personal profiles: only use whitelists and keep them within the specific profiles (see [my repository](https://github.com/chiraag-nataraj/firejail-profiles) for examples of what I mean). I use a `common.inc` which sets up a bunch of rudimentary blacklists and security options (`apparmor`,`caps.drop`,`seccomp`,etc.) which can be overwritten in a program's profile if necessary (`ignore <predicate>`). The nice thing about this approach is that everything in `common.inc` is _truly_ common - it should be true _by default_ in every profile (and only disabled if the program doesn't work with it enabled). And since all of the profiles have whitelists for files and directories in `~` (except for maybe one or two, which I'm working on), it's not at all an issue that `common.inc` doesn't have any blacklists or whitelists of those files.

gitea-mirror commented

2026-05-05 05:49:03 -06:00

Author

Owner

@chiraag-nataraj commented on GitHub (Aug 19, 2018):

We've generally been moving in this direction to the point where I think this can be closed. The profiles have been significantly revamped since the issue was first opened, and we're generally keeping this in mind 🙂

@chiraag-nataraj commented on GitHub (Aug 19, 2018): We've generally been moving in this direction to the point where I think this can be closed. The profiles have been significantly revamped since the issue was first opened, and we're generally keeping this in mind :slightly_smiling_face:

Rows
Columns

[GH-ISSUE #578] Thought: blacklist all .files and folders by default. #410