[GH-ISSUE #1352] What is a security purpose of fairjail?

gitea-mirror commented

2026-05-05 07:10:33 -06:00

Owner

Originally created by @ghost on GitHub (Jun 27, 2017).
Original GitHub issue: https://github.com/netblue30/firejail/issues/1352

Hello, can someone please explain me the purpose of firejail in terms of security?
I was seeking an application to sandbox the environment and found that firejail meets my criteria to try it.

Now, if the main purpose of a sandboxing application is to sandbox everything by default (e.g. act as a blocking but transparent 'firewall' between a real filesystem and the application), why firejail acts exactly vice-versa?

I see that if I have mounted USB storage in /media or a writable directory somewhere whithin the /usr or /var, a fairjail'ed application will be able to write a file to these directories by default. The written files will remain in these folders even after I close the application that did write these files, even using --private option.

Let's now imagine a 0-day privilege escalation or just a local execution vulnerability in that application (e.g. firefox or chrome). An exploit simply gets root and installs some persistent files, or in other case, reads private data from the mounted media.

There is a similar and very related unanswered issue on https://github.com/netblue30/firejail/issues/354, which is important and can't be ignored.

Originally created by @ghost on GitHub (Jun 27, 2017). Original GitHub issue: https://github.com/netblue30/firejail/issues/1352 Hello, can someone please explain me the purpose of firejail in terms of security? I was seeking an application to sandbox the environment and found that firejail meets my criteria to try it. Now, if the main purpose of a sandboxing application is to sandbox everything by default (e.g. act as a blocking but transparent 'firewall' between a real filesystem and the application), why firejail acts exactly vice-versa? I see that if I have mounted USB storage in /media or a writable directory somewhere whithin the /usr or /var, a fairjail'ed application will be able to write a file to these directories by default. The written files will remain in these folders even after I close the application that did write these files, even using --private option. Let's now imagine a 0-day privilege escalation or just a local execution vulnerability in that application (e.g. firefox or chrome). An exploit simply gets root and installs some persistent files, or in other case, reads private data from the mounted media. There is a similar and very related unanswered issue on https://github.com/netblue30/firejail/issues/354, which is important and can't be ignored.

gitea-mirror

2026-05-05 07:10:33 -06:00

closed this issue
added the
information_old
label

gitea-mirror commented

2026-05-05 07:10:36 -06:00

Author

Owner

@Ferroin commented on GitHub (Jun 27, 2017):

Firejail can operate either in whitelisting mode, which is much harder to set up but does what it sounds like you want. Most profiles don't use whitelisting mode because it's much harder to get things to actually work and application updates are more likely to break with whitelisting than blacklisting.

As far as I know, firejail is actually one of the only sandboxing options on Linux that allows for whitelisting without being a full container system.

As far as the specific example you give, I can't really comment, I usually end up using firejail as an extra layer of protection inside a chroot, so that isn't anything I have specific experience with.

As far as #354, it was mostly answered, and the approximate suggestion there of building a custom chroot and running inside that is probably going to be what you need to do to achieve what you want regardless of what sandboxing tool you use unless you decide to use full-blown containers.

@Ferroin commented on GitHub (Jun 27, 2017): Firejail can operate either in whitelisting mode, which is much harder to set up but does what it sounds like you want. Most profiles don't use whitelisting mode because it's much harder to get things to actually work and application updates are more likely to break with whitelisting than blacklisting. As far as I know, firejail is actually one of the only sandboxing options on Linux that allows for whitelisting without being a full container system. As far as the specific example you give, I can't really comment, I usually end up using firejail as an extra layer of protection inside a chroot, so that isn't anything I have specific experience with. As far as #354, it was mostly answered, and the approximate suggestion there of building a custom chroot and running inside that is probably going to be what you need to do to achieve what you want regardless of what sandboxing tool you use unless you decide to use full-blown containers.

gitea-mirror commented

2026-05-05 07:10:38 -06:00

Author

Owner

@netblue30 commented on GitHub (Jun 27, 2017):

Hello, can someone please explain me the purpose of firejail in terms of security?

To prevent bugs such as this one: https://blog.mozilla.org/security/2015/08/06/firefox-exploit-found-in-the-wild/

Now, if the main purpose of a sandboxing application is to sandbox everything by default ...

No, we don't sandbox everything by default, We sandbox only for problems we know about, such as passwords and encryption keys in standard places in the file system. Example: ssh keys in /home/user/.ssh directory.

I have mounted USB storage in /media or a writable directory somewhere whithin the /usr or /var

/media is not a standard place, the user is allowed to have anything in /media. However, you can use firejail to blacklist this directory. By default we don't blacklist it.

With or without a sandbox, writable user directories under /usr or /var are a very bad idea. The user should not be allowed to write in these directories. The only places the user is allowed to write are /home/user and /tmp. Beyond that, you break the UNIX/Linux filesystem hierarchy.

@netblue30 commented on GitHub (Jun 27, 2017): > Hello, can someone please explain me the purpose of firejail in terms of security? To prevent bugs such as this one: https://blog.mozilla.org/security/2015/08/06/firefox-exploit-found-in-the-wild/ > Now, if the main purpose of a sandboxing application is to sandbox everything by default ... No, we don't sandbox everything by default, We sandbox only for problems we know about, such as passwords and encryption keys in standard places in the file system. Example: ssh keys in /home/user/.ssh directory. > I have mounted USB storage in /media or a writable directory somewhere whithin the /usr or /var /media is not a standard place, the user is allowed to have anything in /media. However, you can use firejail to blacklist this directory. By default we don't blacklist it. With or without a sandbox, writable user directories under /usr or /var are a very bad idea. The user should not be allowed to write in these directories. The only places the user is allowed to write are /home/user and /tmp. Beyond that, you break the UNIX/Linux filesystem hierarchy.

gitea-mirror commented

2026-05-05 07:10:41 -06:00

Author

Owner

@chiraag-nataraj commented on GitHub (Jun 27, 2017):

Let's now imagine a 0-day privilege escalation or just a local execution vulnerability in that application (e.g. firefox or chrome). An exploit simply gets root and installs some persistent files, or in other case, reads private data from the mounted media.

Firejail would prevent the application from getting root (at least for most applications - check the profiles; a noroot directive means the root user doesn't even exist in the jailed application's namespace). Reading private data from /media is more serious, which is why I usually end up blacklisting it myself. Then again, I ended up building a bunch of restrictive profiles - you may find them useful (https://github.com/chiraag-nataraj/firejail-profiles).

@netblue30, what is the argument for not blacklisting /media by default? As you say, the user is allowed to have anything in media, so it could very well be a sensitive location.

@chiraag-nataraj commented on GitHub (Jun 27, 2017): > Let's now imagine a 0-day privilege escalation or just a local execution vulnerability in that application (e.g. firefox or chrome). An exploit simply gets root and installs some persistent files, or in other case, reads private data from the mounted media. Firejail would prevent the application from getting root (at least for most applications - check the profiles; a `noroot` directive means the root user doesn't even exist in the jailed application's namespace). Reading private data from /media _is_ more serious, which is why I usually end up blacklisting it myself. Then again, I ended up building a bunch of restrictive profiles - you may find them useful (https://github.com/chiraag-nataraj/firejail-profiles). @netblue30, what is the argument for not blacklisting /media by default? As you say, the user is allowed to have anything in media, so it could very well be a sensitive location.

gitea-mirror commented

2026-05-05 07:10:41 -06:00

Author

Owner

@SkewedZeppelin commented on GitHub (Jun 27, 2017):

/media is not a standard place, the user is allowed to have anything in /media. However, you can use firejail to blacklist this directory. By default we don't blacklist it.

Reading private data from /media is more serious, which is why I usually end up blacklisting it myself.

I still do hope for #1231

@SkewedZeppelin commented on GitHub (Jun 27, 2017): > /media is not a standard place, the user is allowed to have anything in /media. However, you can use firejail to blacklist this directory. By default we don't blacklist it. > Reading private data from /media is more serious, which is why I usually end up blacklisting it myself. I still do hope for #1231

gitea-mirror commented

2026-05-05 07:10:42 -06:00

Author

Owner

@chiraag-nataraj commented on GitHub (Jun 27, 2017):

True. For now, though, you can blacklist /mnt or whitelist /mnt/X if you need to access specific folders inside /mnt (analogous stuff for /media).

@chiraag-nataraj commented on GitHub (Jun 27, 2017): True. For now, though, you can `blacklist /mnt` or `whitelist /mnt/X` if you need to access specific folders inside /mnt (analogous stuff for /media).

gitea-mirror commented

2026-05-05 07:10:44 -06:00

Author

Owner

@SkewedZeppelin commented on GitHub (Jun 27, 2017):

@chiraag-nataraj oh heh I don't even care much about the whitelist part. Just a simple per-profile disable-mnt as described in firejail.config is more then enough. The whitelist part would just allow users to harden profiles even further.

Disable /mnt, /media, /run/mount and /run/media access. By default access
to these directories is enabled.
disable-mnt no

Edit: the commit referenced in #1231 would allow hardening many profiles without any breakage, which would be a big win.

@SkewedZeppelin commented on GitHub (Jun 27, 2017): @chiraag-nataraj oh heh I don't even care much about the whitelist part. Just a simple per-profile disable-mnt as described in firejail.config is more then enough. The whitelist part would just allow users to harden profiles even further. > Disable /mnt, /media, /run/mount and /run/media access. By default access > to these directories is enabled. > disable-mnt no Edit: the commit referenced in #1231 would allow hardening many profiles without *any* breakage, which would be a big win.

gitea-mirror commented

2026-05-05 07:10:45 -06:00

Author

Owner

@netblue30 commented on GitHub (Jun 28, 2017):

OK, I'll bring in a per-profile disable-mnt. I'm not sure what applications will use it.

@netblue30 commented on GitHub (Jun 28, 2017): OK, I'll bring in a per-profile disable-mnt. I'm not sure what applications will use it.

gitea-mirror commented

2026-05-05 07:10:46 -06:00

Author

Owner

@Ferroin commented on GitHub (Jun 29, 2017):

Actually, I could see that being useful as a default for quite a few things. Most of the server software for example could have that added without breaking (nginx for example should never need to access removable media).

@Ferroin commented on GitHub (Jun 29, 2017): Actually, I could see that being useful as a default for quite a few things. Most of the server software for example could have that added without breaking (nginx for example should never need to access removable media).

gitea-mirror commented

2026-05-05 07:10:47 -06:00

Author

Owner

@netblue30 commented on GitHub (Jul 5, 2017):

All set, disable-mnt support is in.

@netblue30 commented on GitHub (Jul 5, 2017): All set, disable-mnt support is in.

gitea-mirror commented

2026-05-05 07:10:48 -06:00

Author

Owner

@g3ngr33n commented on GitHub (Mar 22, 2018):

Firejail using the default profil are mainly focused compatibility, making the sandbox work with most of the distribution Linux, without breaking any function of the target application, it's add a layer of security and will make any exploit harder to success.

That being said, when looking to harden as much a possible, you should not run the default profile but instead, taking a look of the manual (man firejail) and write your own configuration, with all the options that can reduce the capabilities / access as much as possible, depending on your need, your configuration....

For example, I'm using the following profile for firefox

https://paste.ee/p/1pIR8

Now this doesn't fit for everybody, and doing such profile as default isn't a good idea as it broke feature of firefox (sound for video online...) and will certainely not work on most of the Linux distribution, but it offer more security and this fit for my need.

Firejail is a no brainer when you are looking to harden or add an extra layer of security, but it's not a magic tool.

@g3ngr33n commented on GitHub (Mar 22, 2018): Firejail using the default profil are mainly focused compatibility, making the sandbox work with most of the distribution Linux, without breaking any function of the target application, it's add a layer of security and will make any exploit harder to success. That being said, when looking to harden as much a possible, you should not run the default profile but instead, taking a look of the manual (man firejail) and write your own configuration, with all the options that can reduce the capabilities / access as much as possible, depending on your need, your configuration.... For example, I'm using the following profile for firefox https://paste.ee/p/1pIR8 Now this doesn't fit for everybody, and doing such profile as default isn't a good idea as it broke feature of firefox (sound for video online...) and will certainely not work on most of the Linux distribution, but it offer more security and this fit for my need. Firejail is a no brainer when you are looking to harden or add an extra layer of security, but it's not a magic tool.

Rows
Columns

[GH-ISSUE #1352] What is a security purpose of fairjail? #930