[GH-ISSUE #970] firejail allows R/W files outside of the sandbox when run without arguments

gitea-mirror commented

2026-05-05 06:22:55 -06:00

Owner

Originally created by @Emanem on GitHub (Dec 12, 2016).
Original GitHub issue: https://github.com/netblue30/firejail/issues/970

Hi,

Looks like that when one runs a command in firejail without specifying any option (blacklist/whitelist and so on), one can modify a file outside of the sandbox. for example:

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

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.

Originally created by @Emanem on GitHub (Dec 12, 2016). Original GitHub issue: https://github.com/netblue30/firejail/issues/970 Hi, Looks like that when one runs a command in firejail *without* specifying any option (blacklist/whitelist and so on), one can modify a file outside of the sandbox. for example: 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!* 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`.

gitea-mirror

2026-05-05 06:22:55 -06:00

closed this issue
added the
information_old
label

gitea-mirror commented

2026-05-05 06:23:02 -06:00

Author

Owner

@netblue30 commented on GitHub (Dec 13, 2016):

With a few exceptions blacklisted in /etc/firejail/default.profile and some directories blacklisted by default, all the files in the root filesystem should be available by default. I guess you need to blacklist /disk5 (--blacklist or using a custom profile).

@netblue30 commented on GitHub (Dec 13, 2016): With a few exceptions blacklisted in /etc/firejail/default.profile and some directories blacklisted by default, all the files in the root filesystem should be available by default. I guess you need to blacklist /disk5 (--blacklist or using a custom profile).

gitea-mirror commented

2026-05-05 06:23:04 -06:00

Author

Owner

@Emanem commented on GitHub (Dec 13, 2016):

Hi, thanks for coming back - I have to say this doesn't make much sense to me.
My expectation is that by virtue of not specifying an option, firejail would let the child process run as myself with all permissions but at least never be able to modify files outside of the sandbox. This appears to me as a leaky sandbox.

Of course if I start blacklisting all that I need, then I would be able to make it happen, but still, I thought the default behaviour would have been max security first.
What am I missing?

@Emanem commented on GitHub (Dec 13, 2016): Hi, thanks for coming back - I have to say this doesn't make much sense to me. My expectation is that by virtue of not specifying an option, *firejail* would let the child process run as myself with all permissions but at least **never** be able to modify files **outside** of the sandbox. This appears to me as a _leaky_ sandbox. Of course if I start blacklisting all that I need, then I would be able to make it happen, but still, I thought the default behaviour would have been *max security* first. What am I missing?

gitea-mirror commented

2026-05-05 06:23:08 -06:00

Author

Owner

@netblue30 commented on GitHub (Dec 13, 2016):

but at least never be able to modify files outside of the sandbox

By default the full filesystem is sandboxed, with all the mount points. There is no way one can guess what you need or what you don't need inside the sandbox.

@netblue30 commented on GitHub (Dec 13, 2016): > but at least never be able to modify files outside of the sandbox By default the full filesystem is sandboxed, with all the mount points. There is no way one can guess what you need or what you don't need inside the sandbox.

gitea-mirror commented

2026-05-05 06:23:11 -06:00

Author

Owner

@Emanem commented on GitHub (Dec 13, 2016):

And that would be fine - but it looks like it's not happening. If by default the whole filesystem is sandboxed, why am I able to create a new file on a separate mount (/disk5) and write on it without any restriction?
Also, why am I able to open it, write on it and those writes are staying after the firejail process is closed?

@Emanem commented on GitHub (Dec 13, 2016): And that would be fine - but it looks like it's not happening. If by default the whole filesystem is sandboxed, why am I able to create a new file on a separate mount (`/disk5`) and write on it without any restriction? Also, why am I able to open it, write on it and those writes are staying after the *firejail* process is closed?

gitea-mirror commented

2026-05-05 06:23:15 -06:00

Author

Owner

@netblue30 commented on GitHub (Dec 13, 2016):

By default the whole filesystem is sandboxed means the whole filesystem is visible in the sandbox.

@netblue30 commented on GitHub (Dec 13, 2016): By default the whole filesystem is sandboxed means the whole filesystem is visible in the sandbox.

gitea-mirror commented

2026-05-05 06:23:18 -06:00

Author

Owner

@Emanem commented on GitHub (Dec 13, 2016):

I get and I'm fine, but should the entire system by default writable only inside the sandbox?
Just to make sure I get this right, are you saying it's ok to modify an existing file inside the sandbox and those changes to be saved also outside of the sandbox when I shut the sandbox down?

@Emanem commented on GitHub (Dec 13, 2016): I get and I'm fine, but should the entire system by default *writable only inside the sandbox*? Just to make sure I get this right, are you saying it's ok to modify an existing file *inside* the sandbox and those changes to be saved also outside of the sandbox when I shut the sandbox down?

gitea-mirror commented

2026-05-05 06:23:21 -06:00

Author

Owner

@netblue30 commented on GitHub (Dec 14, 2016):

it's ok to modify an existing file inside the sandbox and those changes to be saved also outside of the sandbox

In most cases yes. A browser running in the sandbox is expected to save downloads, bookmarks, and configuration; a bittorrent client should be able to save files on the disk etc. The defaults are set for browsing and other network client utilities. But you can change all this using --blackist, --whitlist, --overlay and a bunch of other commands.

@netblue30 commented on GitHub (Dec 14, 2016): > it's ok to modify an existing file inside the sandbox and those changes to be saved also outside of the sandbox In most cases yes. A browser running in the sandbox is expected to save downloads, bookmarks, and configuration; a bittorrent client should be able to save files on the disk etc. The defaults are set for browsing and other network client utilities. But you can change all this using --blackist, --whitlist, --overlay and a bunch of other commands.

gitea-mirror commented

2026-05-05 06:23:24 -06:00

Author

Owner

@Emanem commented on GitHub (Dec 14, 2016):

The defaults are set for browsing and other network client utilities

Then a virus/malware could modify an executable on my home (unless one specifies --private) and then run every time one logs in. That's not great, but thanks for confirming it. This article, http://www.linux-magazine.com/Issues/2015/173/Firejail, is clearly wrong big time.

I shall close this bug.

@Emanem commented on GitHub (Dec 14, 2016): > The defaults are set for browsing and other network client utilities Then a virus/malware could modify an executable on my home (unless one specifies `--private`) and then run every time one logs in. That's not great, but thanks for confirming it. This article, http://www.linux-magazine.com/Issues/2015/173/Firejail, is clearly wrong **big time**. I shall close this bug.

gitea-mirror commented

2026-05-05 06:23:26 -06:00

Author

Owner

@curiosity-seeker commented on GitHub (Dec 14, 2016):

Then a virus/malware could modify an executable on my home (unless one specifies --private) and then run every time one logs in.

No, that's incorrect. First of all, your browser can only access those files/folders in your home which are explicitly whitelisted in the respective profile. Additionally, virtually all autostart locations (and many more) are explicitly blacklisted in disable-common.inc which is included in every profile.

I suggest that you make yourself familiar with Firejail before making such unfunded claims.

@curiosity-seeker commented on GitHub (Dec 14, 2016): > Then a virus/malware could modify an executable on my home (unless one specifies --private) and then run every time one logs in. No, that's incorrect. First of all, your browser can only access those files/folders in your home which are explicitly whitelisted in the respective profile. Additionally, virtually all autostart locations (and many more) are explicitly blacklisted in disable-common.inc which is included in every profile. I suggest that you make yourself familiar with Firejail before making such unfunded claims.

gitea-mirror commented

2026-05-05 06:23:28 -06:00

Author

Owner

@Emanem commented on GitHub (Dec 14, 2016):

This is not an unfunded claim: please see above example, my /disk5 is outside of my /home and if I were to run some malware, it could find an executable under there and install itself/replicate/... I had to explicitly blacklist it to obtain the desired effect (which was supposed to be there by default as cited in linux-magazine link provided).

@Emanem commented on GitHub (Dec 14, 2016): This is not an unfunded claim: please see above example, my `/disk5` is outside of my `/home` and if I were to run some malware, it could find an executable under there and install itself/replicate/... I had to **explicitly** _blacklist_ it to obtain the desired effect (which was supposed to be there by default as cited in *linux-magazine* link provided).

gitea-mirror referenced this issue

2026-05-05 10:06:22 -06:00

[PR #660] [MERGED] Add new skypeforlinux profile. #3703

Rows
Columns

[GH-ISSUE #970] firejail allows R/W files outside of the sandbox when run without arguments #660