Creation of blacklisted or read-only files

[SYN-cook]

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

[SYN-cook]

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.

[netblue30]

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.

[SYN-cook]

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

[chiraag-nataraj]

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.