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

2
  • 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, 2016 at 10:33
  • @Shiki /disk5/... is mounted outside of my home, that's why I'm very surprised...
    – Emanuele
    Dec 12, 2016 at 10:42

2 Answers 2

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

2
  • from the man page under --nonewprivs: "This option is enabled by default if seccomp filter is activated."
    – user198350
    Aug 22, 2023 at 6: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. Aug 22, 2023 at 7: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.

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, 2016 at 23:50

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .