Just installed firejail on Ubuntu 16.04 (version 0.9.38) and according to this linux-magazine article, by default it should make R/O the entire filesystem:

The programs in the sandbox have only read access to all directories and are thus unable to manipulate any important files.

Now, I tried the following on my computer:

  1. touch /disk5/test.txt
  2. firejail gvim /disk5/test.txt
  3. modify the file and save it (wq!)
  4. cat /disk5/test.txt
  5. does display changes done by gvim during firejail session!

Is this expected behaviour? Wasn't firejail supposed to protect me from overwriting the original file? What have I done wrong? Please note that /disk5 is mounted in the root filesystem, outside of my /home.

Raised a bug on github

  • You forgot to append the --private flag to Firejail. True, the man page states Only /home and /tmp are writable. Are you sure you are not trying this under your Home? Or a folder/disk mounted under your Home or something like that? Checking the man page is also useful, there are tons of various options for Firejail. man firejail` and see which other arguments you might need. – Apache Dec 12 '16 at 10:33
  • @Shiki /disk5/... is mounted outside of my home, that's why I'm very surprised... – Emanuele Dec 12 '16 at 10:42

firejail is not a magical tool that makes everything right. It's a security tool that lets you define your own rules on how to deal with stuff. For example, these arguments:

firejail --noprofile

Will not give any protection at all. Because you didn't specify any constraints, and firejail is permissive by default. In order to make some dirs read-only, you should write it explicitely. Something like:

firejail --noprofile --read-only=/ --read-only=~ --read-only=/tmp

(I wrote /, ~ and /tmp separately because firejail has a somewhat surprising behaviour of sorting your directives by some not-so-trivial rules and making its own ~ mounts in the middle.)

Also, without any --caps.drop=all arguments, --seccomp and such your programs won't be secure anyway. Because the process could communicate with other processes via unix sockets, abstract sockets etc, exploiting their bugs. If you want a relatively OK "jail", add at least seccomp, caps.drop=all, and nonewprivs directives.

EDIT: the quote you mentioned is probably just wrong. (Or so I think.) It's more complex than just "everything is read-only".

| improve this answer | |

Why would you keep your programs in a non-standard Unix directory such as /disk5? You are definitely asking for trouble. Store your executables in the regular places, such as /bin, /usr/bin. /usr/local/bin, or even /opt. Make sure all your executables are owned by root and regular users don't have write access to them. Linux is a Unix system, just follow the Unix rules and you'll be safe.

| improve this answer | |
  • 4
    I can't really, especially if those are 3rd party software such as games from steam, my own compiled executables that I'm developing/building, etc etc... I wouldn't and couldn't definitely install those under the system bin paths... – Emanuele Dec 20 '16 at 23:50

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.