[GH-ISSUE #784] single instance applications - possible security breach #531

Closed
opened 2026-05-05 06:03:38 -06:00 by gitea-mirror · 3 comments
Owner

Originally created by @lalbers on GitHub (Sep 15, 2016).
Original GitHub issue: https://github.com/netblue30/firejail/issues/784

Hi,

first of all i wanna thank netblue30 for his awesome tool firejail. i really enjoyed it and its absolutely useful.

Maybe i'm wrong or i forgot to block something important, but in my case i'm able to bypass the firebox sandbox by opening single instance applications.

Here ist an example:
firejail --private --seccomp.drop=all --caps.drop=all

Reading profile /etc/firejail/default.profile
Reading profile /etc/firejail/disable-common.inc
Reading profile /etc/firejail/disable-programs.inc
Reading profile /etc/firejail/disable-passwdmgr.inc
Warning: user namespaces not available in the current kernel.

** Note: you can use --noprofile to disable default.profile **

Parent pid 26650, child pid 26651
Warning: /sbin directory link was not blacklisted
Warning: /usr/sbin directory link was not blacklisted

Warning: syscall all not found
Child process initialized

When i execute an 'ls' command, home dir is totally empty. So I'm in sandboxed environment.
When i launch firefox (and i got another instance running) it starts up with all my plugins and booksmarks loaded. I can also pass arguments to firefox, which caus firefox to download some files outside the sandbox. This is maybe more critical with other single instance applications.

Environment:
4.7.3-1-MANJARO
KDE-PLASMA Desktop
firejail version 0.9.40

Also encountered the problem with dolphin service, it has already been discussed in another issue. But it's also possible to send commands to the service, which can cause changes in the real filesystem.

Originally created by @lalbers on GitHub (Sep 15, 2016). Original GitHub issue: https://github.com/netblue30/firejail/issues/784 Hi, first of all i wanna thank netblue30 for his awesome tool firejail. i really enjoyed it and its absolutely useful. Maybe i'm wrong or i forgot to block something important, but in my case i'm able to bypass the firebox sandbox by opening single instance applications. Here ist an example: firejail --private --seccomp.drop=all --caps.drop=all ``` Reading profile /etc/firejail/default.profile Reading profile /etc/firejail/disable-common.inc Reading profile /etc/firejail/disable-programs.inc Reading profile /etc/firejail/disable-passwdmgr.inc Warning: user namespaces not available in the current kernel. ** Note: you can use --noprofile to disable default.profile ** Parent pid 26650, child pid 26651 Warning: /sbin directory link was not blacklisted Warning: /usr/sbin directory link was not blacklisted Warning: syscall all not found Child process initialized ``` When i execute an 'ls' command, home dir is totally empty. So I'm in sandboxed environment. When i launch firefox (and i got another instance running) it starts up with all my plugins and booksmarks loaded. I can also pass arguments to firefox, which caus firefox to download some files outside the sandbox. This is maybe more critical with other single instance applications. Environment: 4.7.3-1-MANJARO KDE-PLASMA Desktop firejail version 0.9.40 Also encountered the problem with dolphin service, it has already been discussed in another issue. But it's also possible to send commands to the service, which can cause changes in the real filesystem.
gitea-mirror 2026-05-05 06:03:38 -06:00
Author
Owner

@chiraag-nataraj commented on GitHub (Sep 15, 2016):

First, just a note: you can't drop all syscalls. First because that would render the application completely incapable and second because that isn't a valid option (as the output suggests).

On to your real concern. Unfortunately, Firefox (and Dolphin and Chrome and Libreoffice et al) are designed like this because they don't want multiple instances messing with one set of config files.

There are two ways to fix this:

  1. Sandbox the first instance. This is what I do and is the easiest (and universal) solution. That way, no matter how many times you open a Firefox instance in whatever context, it will be sandboxed.
  2. Try to disable connecting to the open instance. With Firefox, you can try this with --no-remote. This totally depends on the people who wrote the application and whether they included such an option.
<!-- gh-comment-id:247484167 --> @chiraag-nataraj commented on GitHub (Sep 15, 2016): First, just a note: you can't drop all syscalls. First because that would render the application completely incapable and second because that isn't a valid option (as the output suggests). On to your real concern. Unfortunately, Firefox (and Dolphin and Chrome and Libreoffice et al) are designed like this because they don't want multiple instances messing with one set of config files. There are two ways to fix this: 1) Sandbox the first instance. This is what I do and is the easiest (and universal) solution. That way, no matter how many times you open a Firefox instance in whatever context, it will be sandboxed. 2) Try to disable connecting to the open instance. With Firefox, you can try this with `--no-remote`. This totally depends on the people who wrote the application and whether they included such an option.
Author
Owner

@lalbers commented on GitHub (Sep 16, 2016):

hey chiraag-nataraj,

thx for you fast reply and the note with syscall.

I also figured out the --no-remote argument. A more secure solution would be another user which is only used for sandboxed applications.

My concern is, that a malicious software can use these facts to break out of the sandbox. What I would see as a security risk. It is not mandatory firejails fault, i was just hoping there are options to block this behavior, except the workaround with another user.

<!-- gh-comment-id:247487610 --> @lalbers commented on GitHub (Sep 16, 2016): hey chiraag-nataraj, thx for you fast reply and the note with syscall. I also figured out the --no-remote argument. A more secure solution would be another user which is only used for sandboxed applications. My concern is, that a malicious software can use these facts to break out of the sandbox. What I would see as a security risk. It is not mandatory firejails fault, i was just hoping there are options to block this behavior, except the workaround with another user.
Author
Owner

@chiraag-nataraj commented on GitHub (Sep 16, 2016):

As I said, the easiest (and safest) solution is to sandbox the first instance. This is easy in the case of Firefox, but a bit harder with e.g. Dolphin, since you want to allow it access to different files in different contexts (i.e. under different applications). That's a whole different story though. If the first instance is sandboxed, it's not going to be able to break out of the jail (barring security holes of course).

The fundamental problem is that you have to sandbox pretty much every application to get enhanced security. For example, denying network access whenever a program doesn't need it and tightly restricting whichever network-facing programs you do run. Otherwise, you end up in a situation where any network-facing application is liable to be exploited (this includes services!) and then all your sandboxing is worthless. It doesn't matter if Firefox is sandboxed if the exploit was through Google Chrome or ssh and you happened to be running them unsandboxed.

Blocking applications from realizing they're open is super hard to do if you're not that application. For example, even PID namespaces don't stop it apparently (at least with Firefox). Most likely, they look for lock files in the configuration directories, which are a bad idea to mess with since you could end up corrupting the config files. You'd end up having to figure out how each application does it - traditional lock file, abstract socket, unix socket, whatever - and set up rules for each one while also managing stuff to make sure config files aren't destroyed by multiple instances writing to them. All in all a major headache and really something the application developers should be thinking about.

<!-- gh-comment-id:247488996 --> @chiraag-nataraj commented on GitHub (Sep 16, 2016): As I said, the easiest (and safest) solution is to sandbox the first instance. This is easy in the case of Firefox, but a bit harder with e.g. Dolphin, since you want to allow it access to different files in different contexts (i.e. under different applications). That's a whole different story though. If the first instance is sandboxed, it's not going to be able to break out of the jail (barring security holes of course). The fundamental problem is that you have to sandbox pretty much every application to get enhanced security. For example, denying network access whenever a program doesn't need it and tightly restricting whichever network-facing programs you _do_ run. Otherwise, you end up in a situation where any network-facing application is liable to be exploited (this includes services!) and then all your sandboxing is worthless. It doesn't matter if Firefox is sandboxed if the exploit was through Google Chrome or ssh and you happened to be running them unsandboxed. Blocking applications from realizing they're open is super hard to do if you're not that application. For example, even PID namespaces don't stop it apparently (at least with Firefox). Most likely, they look for lock files in the configuration directories, which are a bad idea to mess with since you could end up corrupting the config files. You'd end up having to figure out how each application does it - traditional lock file, abstract socket, unix socket, whatever - and set up rules for each one while also managing stuff to make sure config files aren't destroyed by multiple instances writing to them. All in all a major headache and really something the application developers should be thinking about.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/firejail#531
No description provided.