github-starred/firejail

Fork 0

mirror of https://github.com/netblue30/firejail.git synced 2026-05-15 14:16:14 -06:00

[GH-ISSUE #1011] Creation of blacklisted or read-only files #688

New issue

Closed

opened 2026-05-05 06:27:03 -06:00 by gitea-mirror · 4 comments

gitea-mirror commented

2026-05-05 06:27:03 -06:00

Owner

Originally created by @SYN-cook on GitHub (Dec 28, 2016).
Original GitHub issue: https://github.com/netblue30/firejail/issues/1011

In the moment, firejail can blacklist files or set them read-only, if the files already exist. But if a file to be marked as read-only or as blacklisted doesn't exist yet, firejail won't prevent its creation.

This is for sure entirely unproblematic in most cases, but I see a problem in particular with the bash configuration file zoo. It is probably safe to assume that on most systems the set of bash configuration files is incomplete. In a Debian home folder, for example, there are by default only .bashrc, .bash_logout and .profile.

Now if a program in a firejail sandbox would create a new .bash_profile or .bash_login file (both read-only via disable-common.inc) or a new .bash_aliases file, it could basically write there anything it wanted... and have it executed on next login. I'm not familiar with other shells, but there might be similar problems, too.

Thus, a nice-to-have feature would be to prevent the creation of blacklisted or read-only files.

For the issue with bash there are several easy workarounds of course: E.g. creating an empty file ~/.bash_aliases and renaming ~/.profile to ~/.bash_profile solves the problem for a default Debian desktop.

#1010

Originally created by @SYN-cook on GitHub (Dec 28, 2016). Original GitHub issue: https://github.com/netblue30/firejail/issues/1011 In the moment, firejail can blacklist files or set them read-only, if the files already exist. But if a file to be marked as read-only or as blacklisted doesn't exist yet, firejail won't prevent its creation. This is for sure entirely unproblematic in most cases, but I see a problem in particular with the bash configuration file zoo. It is probably safe to assume that on most systems the set of bash configuration files is incomplete. In a Debian home folder, for example, there are by default only `.bashrc`, `.bash_logout` and `.profile`. Now if a program in a firejail sandbox would create a new `.bash_profile` or `.bash_login` file (both read-only via disable-common.inc) or a new `.bash_aliases` file, it could basically write there anything it wanted... and have it executed on next login. I'm not familiar with other shells, but there might be similar problems, too. Thus, a nice-to-have feature would be to prevent the creation of blacklisted or read-only files. For the issue with bash there are several easy workarounds of course: E.g. creating an empty file `~/.bash_aliases` and renaming `~/.profile` to `~/.bash_profile` solves the problem for a default Debian desktop. #1010

gitea-mirror

2026-05-05 06:27:03 -06:00

closed this issue
added the
enhancement
label

gitea-mirror commented

2026-05-05 06:27:08 -06:00

Author

Owner

@SYN-cook commented on GitHub (Dec 28, 2016):

Also, many distributions are shipped without critical folders like autostart or ~/bin... they are created as required, and as long as they don't exist, even firejailed applications can make and fill them with arbitrary data.

@SYN-cook commented on GitHub (Dec 28, 2016): Also, many distributions are shipped without critical folders like autostart or ~/bin... they are created as required, and as long as they don't exist, even firejailed applications can make and fill them with arbitrary data.

gitea-mirror commented

2026-05-05 06:27:10 -06:00

Author

Owner

@netblue30 commented on GitHub (Dec 29, 2016):

Yes it's a nice feature, I'll mark it as an enhancement, although I have no idea how to do it at this moment.

@netblue30 commented on GitHub (Dec 29, 2016): Yes it's a nice feature, I'll mark it as an enhancement, although I have no idea how to do it at this moment.

gitea-mirror commented

2026-05-05 06:27:13 -06:00

Author

Owner

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

@netblue30, just to provide a little more input :)

Do you think it could be helpful to write a warning to the syslog when a blacklisted file from disable-common.inc is freshly created (kernel provides the inotify API for such things)? From an attackers perspective, it would increase the risk of discovery to some extent....
Further in this direction - since probably only a small minority of users regularly monitor their syslogs - one could also increase the verbosity and display some kind of message whenever a file from disable-common.inc is newly created. But although I think that would be useful from the perspective of security, I acknowledge that firejail is just as much about being easy to use and not getting in the way, and I'm not sure if we want our users to have making sense of (cryptic) warning messages.

An alternative way to handle this issue would be to employ whitelisting in more profiles. Also this has its downsides (with whitelisting, everything tends to be more restrictive, which leads to an increased risk of breaking functionality in one way or another), but an extensive use of whitelisting would be more compatible with the way Firejail works right now. When going this direction, having a profile switch at hand like "whitelist everything that is not hidden (in the root of user home)" would be very helpful, I guess.

A very similar discussion about blacklisting, that inspired this comment, is/has been going on in #578.

@SYN-cook commented on GitHub (Apr 4, 2017): @netblue30, just to provide a little more input :) Do you think it could be helpful to write a warning to the syslog when a blacklisted file from disable-common.inc is freshly created (kernel provides the inotify API for such things)? From an attackers perspective, it would increase the risk of discovery to some extent.... Further in this direction - since probably only a small minority of users regularly monitor their syslogs - one could also increase the verbosity and display some kind of message whenever a file from disable-common.inc is newly created. But although I think that would be useful from the perspective of security, I acknowledge that firejail is just as much about being easy to use and not getting in the way, and I'm not sure if we want our users to have making sense of (cryptic) warning messages. An alternative way to handle this issue would be to employ whitelisting in more profiles. Also this has its downsides (with whitelisting, everything tends to be more restrictive, which leads to an increased risk of breaking functionality in one way or another), but an extensive use of whitelisting would be more compatible with the way Firejail works right now. When going this direction, having a profile switch at hand like "whitelist everything that is not hidden (in the root of user home)" would be very helpful, I guess. A very similar discussion about blacklisting, that inspired this comment, is/has been going on in #578.

gitea-mirror commented

2026-05-05 06:27:16 -06:00

Author

Owner

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

In profile files, you can use

mkdir <directory to blacklist>
blacklist <directory to blacklist>

which ensures the directory exists and cannot be accessed. If you want to do this for a file, use mkfile instead of mkdir. Note that this solution leads to the files/directories being created if they don't exist, but if you're okay with random empty directories around the place, this seems to work as you want.

@chiraag-nataraj commented on GitHub (Jul 22, 2018): In profile files, you can use ``` mkdir <directory to blacklist> blacklist <directory to blacklist> ``` which ensures the directory exists and cannot be accessed. If you want to do this for a file, use `mkfile` instead of `mkdir`. Note that this solution leads to the files/directories being created if they don't exist, but if you're okay with random empty directories around the place, this seems to work as you want.

gitea-mirror referenced this issue

2026-05-05 10:06:39 -06:00

[PR #694] [MERGED] typo #688 #3718

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/firejail#688

No description provided.

Rows
Columns