Allow symlinked /opt

[dehnhard]

Firejail 0.9.52 (Debian Stretch / Backports repository)

First install of Firejail. It works well for me with the default profiles, though I run into a problem with google-chrome, which is caused by the fact that on that system /opt is symlinked to /home/opt for disk space reasons (/ is on a fast but small SSD, while /home is on a larger HD). So firejail google-chrome results in Error: no suitable /usr/bin/google-chrome executable found because that path is actually a symlink itself to /opt/google/chrome/google-chrome (installed from official Google Debian package), which maps to /home/opt/google/chrome/google-chrome in this setup.

I'd like to ask for either:

• A way to tell firejail that /home/opt is a valid path for executables. If that's already possible I didn't find it in the documentation or the configuration files.
• Or to have firejail detect that /opt is a symlink and automatically allow the target path.

[Vincent43]

Create /etc/firejail/google-chrome.local and add allusers line inside. You may need to tweak firejail apparmor profile if you use it.

EDIT: Above won't work when whitelist is used inside profile (and it is used). You have to move /home/opt somewhere else, i.e. /home/<user>/opt then disable noexec ${HOME} and add whitelist /home/<user>/opt.

[dehnhard]

Thanks for the suggestion, but it still reports the same.

There seems to be something Chrome Profile specific as in firejail --allusers bash that chrome installation is at least executable (although it fails with some chrome sandbox error).

(apparmor is not installed)

[Vincent43]

Chrome Profile profile uses whitelist under /home/<user> which makes --allusers ineffective. Try firejail --noprofile --allusers --whitelist=/home/<user>/.bashrc bash to see what I mean. /home/opt is really unfortunate choice in that case. I'm afraid you have to choose some other dir to use it with firejail.

[dehnhard]

@Vincent43 Thanks for the support. I now understand that the whitelistable directories are fixed and not configurable in firejail. Also allusers would have been nice in this specific case, but still a workaround. To move opt into the users home directory doesn't feel right to me, so I solved this problem by moving opt back in place and only symlinking the subdirectories which really are too large for the partition - they incidentally don't use firejail (e.g. the Android SDK).

Although I solved my problem for now, I'd like to keep this issue open for the devs to consider to implement such a configurability and/or the symlinking. I think it would be good for admins and developers of Linux distributions to have this freedom of choice instead of being restricted to a fixed structure.

[Vincent43]

Generally whitelistable directories aren't fixed and are configurable but those directly under /home, i.e. /home/foo, /home/bar other than your user home directory are treated in special way. That's why I wrote that /home/opt is unfortunate choice in that case. Probably any other directory on system would work better with firejail.

[dehnhard]

Then let's assume an admin introduces a new directory /alt for alternative software (similar to /opt, but deliberately not taken from FHS folder definitions). One software may be named foo with a binary bar in /alt/foo/bin/bar. How would that admin configure foo in firejail?

[Vincent43]

firejail --ignore=apparmor /alt/foo/bin/bar would work out of the box. You,re right that whitelisting is currently limited to user home, /dev, /media, /mnt, /opt, /srv, /var, and /tmp (plus /bin and /lib while using --private-*). If you want to write custom sandboxes from scratch you may try bubblewrap or nsjail.

[dehnhard]

Sounds like making those (supposedly hard-coded) directories you mentioned configurable would give much flexibility at (probably) a low cost. The defaults are arguably very sane for any standard Linux, but this would allow adaptability and also easy portability to other file structures (e.g. BSD flavors). But as stated I solved my problem without it and just leave it as an idea.

[chiraag-nataraj]

So this is basically yet another vote for being able to whitelist arbitrary directories 👍

[chiraag-nataraj]

Let's move discussion over to #2041