6

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

Emanuele
  • 711
  • 1
  • 6
  • 22
  • 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

2 Answers2

4

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

VasyaNovikov
  • 3,366
  • 3
  • 25
  • 33
  • from the `man` page under `--nonewprivs`: "This option is enabled by default if seccomp filter is activated." – user198350 Aug 22 '23 at 06:18
  • @user598527 please feel free to make any edits you wish. I'm not using firejail for a number of years already, having migrated to bubblewrap. I don't really remember anymore. – VasyaNovikov Aug 22 '23 at 07:44
-3

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.

joegasca
  • 1
  • 5
    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