Overruled choice and firejail

Another case of user hostile limitations and overruled choice ([1]):

I regularly use firejail, a sandbox tool, to reduce the risk of security breaches and programs (or downloaded contents viewed in programs) misbehaving.* Today, I was trying to listen to a downloaded music file, the filename of which contained a comma. I started it with my usual bash-script wrapping a firejailed mplayer—and was met with an “Error: “[filename]” is an invalid filename: rejected character: “,””.** Note how this makes no mention of what program or sub-functionality of that program caused/detected/whatnot the error, nor gives any true and valid reason—as the filename (cf. below) is perfectly valid.

*Note that, apart from bugs, there are many software makers who have radically different ideas as to what they are allowed to and should do than many users and/or specifically I. Consider e.g. “phone home” functionality.

**Where I have replaced the actual filename with “[filename]”. I caution that the original quotes might have been distorted by WordPress—as might “Wordpress”, which I write with a “p” not a “P”. Cf. [1].

After some experiments with the ls* command, I could conclude that (a) my file system has no objections to the filename, (b) ls has no objections to the filename, (c) even firejail, it self, has no objections to calling ls with the filename,** but that (d) firejail objects to using this filename in a “whitelist”***. Firstly, this is an extremely disputable decision, as there are hardly ever legitimate reasons to artificially restrict users (and, apart from the above, I cannot recall ever having problems with commata in filenames in any other context). Secondly, the error message is absolutely and utterly inexcusable—an acceptable error message might have read “firejail: “[filename]” is not a valid name for whitelisting: rejected character: “,””. I note, in particular, that (a) it is never acceptable to assume that the user calls a certain program directly and will automatically know what program is to blame, (b) firejail, by its nature, is always used in combination with some other program and correspondingly must make clear whether a certain error comes (directly or indirectly) from firejail or from the other program, (c) as filenames can enter firejail by different roads, it must make clear what road is affected.

*This command just lists file information, so a potentially hostile music file cannot really do any damage even absent firejail.

**But this might simply be a result of firejail being agnostic of the nature of the arguments sent to the “real” program, in this case ls resp. mplayer.

***A means to tell firejail what files may be accessed. An opposite blacklist mechanism tells firejail what files may not be accessed. Note that with mplayer, which per default underlies stricter rules, whitelisting is necessary, while it is optional with ls. Indeed, this points to a possible further point of criticism: it is not a given that a tool will fail just because a certain file cannot be whitelisted, and it would, then, be better for firejail to merely print a warning message and continue with execution. Why should a “firejail ls [filename]” work, while a “firejail - -whitelist=[filename] ls [filename]” leads to an error message? Similarly, why should “firejail - -whitelist=[filename] ls [completely different filename]” lead to an error message?

Generally, firejail has proven quite problematic in terms of arbitrary (or arbitrary seeming, cf. excursion) restrictions, poor usability, and whatnot. For instance, a natural use case is to whitelist the home directory of the current user (while preventing a number of other accesses, including to the Internet, to public directories, and maybe a sub-directory or specific files in the home directory). But this results in “Error: invalid whitelist path /home/[username]”. This is an intolerable restriction, as it should be up to the user and the user only what decisions he allows here. Specifically, the result with my script to play music (and another to view movies) is that I must put my files in a sub-directory of the home directory, which is a nuisance.* Moreover, the error message is, again, very weak. (Yes, this time the issue of whitelisting is mentioned, but neither that firejail is the culprit, nor the exact issue, viz. why this was not allowed.)

*To this note (a) that I reject the idiocy of pseudo-standard directories like “Movies” and “Music” in general and in principle, as a bad idea, (b) that these would be entirely redundant in my case, as I use separate users for this division (just like I have separate users for e.g. surfing, writing, and business activities). Indeed, while whitelisting the home directory, a restriction that prevents the automatic creation of such directories by user-hostile tools would be an obvious use case.

For instance, I had once shuffled off some user files to a directory /d2,* and later tried to access one of the files using firejail. The result? “Error: invalid whitelist path”. As research showed, there are only a limited set of directories below the root that firejail allows, and (the created by me) directory /d2 was not in this limited set. Very similar criticism as with home directories apply. To my recollection, making matters worse, this set of directories was hard-coded, where it should have been configurable, even be it on the system level (instead of the user level).

*I have my “root” and “home” directory trees on separate partitions and the latter happened to be full. This shuffle was a very temporary workaround.

Another issue is the mixture of whitelisting and blacklisting that is used, which is both inconsistent and can lead to odd effects. It would be better to, for most tools, simply consider everything blacklisted and then to whitelist exactly what the tool legitimately needs. (The aforementioned ls is an exception, where the reverse approach seems natural, at least with regard to files, but not, of course, rights like network access.) In all fairness, there is room to discuss the degree to which the firejail developers are to blame and to what degree the distributions that contain firejail.*

*Which have a considerable influence through delivery of configuration files. For instance, until a little less than a year ago, I was a Debian user, and Debian had a very lax attitude, which made use more comfortable, but also reduced the benefit of using firejail. Gentoo, my current distribution, takes a much more stringent attitude. While I prefer this stringency in the long term, it did make the switch from Debian to Gentoo unnecessarily painful. As to Gentoo, there is a lot of incompetence too, in that all user changes are supposed to go in “.local” files that are included during reading of the main “.profile” file for the program at hand. (For instance, there is a file mplayer.profile, which is read, and a file mplayer.local, which is merely included—but mplayer.profile does things that I cannot, or not trivially, undo through mplayer.local, which is contrary to my right to configure my system as I see fit.)

Excursion on possible justifications:
At least with /d2 (cf. above), I could imagine a justifying scenario relating to firejail being a SUID* program, that there might be some way for a user to gain illicit rights if whitelisting directories directly under the root directory (i.e. /). This is speculation, however, and it should have been stated much more clearly, if this was actually the case. It does not justify the home directory issue, even if true, and I cannot see how it would justify the comma issue—if in doubt, firejail should perform better sanitation, not throw errors.

*A program that starts with other rights than the user who calls it and then (if programmed correctly!) drops any additional rights as soon as possible.

Advertisement