[GH-ISSUE #939] Isolate IPC #642

Closed
opened 2026-05-05 06:20:05 -06:00 by gitea-mirror · 13 comments
Owner

Originally created by @KOLANICH on GitHub (Nov 26, 2016).
Original GitHub issue: https://github.com/netblue30/firejail/issues/939

From the faq:

Firefox doesn’t open in a new sandbox. Instead, it opens a new tab in an existing Firefox instance.

This means firejail doesn't filter IPC. It's a big flaw because it allows sandbox escape. For example a malware in a sandbox can monitor if FF is launched and if it is it can launch a ff with an URL as an argument which will cause an unsandboxed FF open a tab with a malicious webpage causing a data leak or a RCE.

Originally created by @KOLANICH on GitHub (Nov 26, 2016). Original GitHub issue: https://github.com/netblue30/firejail/issues/939 From the faq: >Firefox doesn’t open in a new sandbox. Instead, it opens a new tab in an existing Firefox instance. This means firejail doesn't filter IPC. It's a big flaw because it allows sandbox escape. For example a malware in a sandbox can monitor if FF is launched and if it is it can launch a ff with an URL as an argument which will cause an unsandboxed FF open a tab with a malicious webpage causing a data leak or a RCE.
gitea-mirror 2026-05-05 06:20:05 -06:00
Author
Owner

@0xBRM commented on GitHub (Nov 26, 2016):

Is this true? I remember back when I used firejail I launched mpv from firefox using an extension and mpv did not have access to ~/.config/mpv/mpv.conf.

<!-- gh-comment-id:263077500 --> @0xBRM commented on GitHub (Nov 26, 2016): Is this true? I remember back when I used firejail I launched mpv from firefox using an extension and mpv did not have access to ~/.config/mpv/mpv.conf.
Author
Owner

@valoq commented on GitHub (Nov 26, 2016):

@KOLANICH Why do you think that means you can escape the sandbox? That won't work. If malware in a sandbox executes firefox or any other program, that program will be inside the sandbox as well.
I don't understand how you even got the idea.

<!-- gh-comment-id:263079365 --> @valoq commented on GitHub (Nov 26, 2016): @KOLANICH Why do you think that means you can escape the sandbox? That won't work. If malware in a sandbox executes firefox or any other program, that program will be inside the sandbox as well. I don't understand how you even got the idea.
Author
Owner

@KOLANICH commented on GitHub (Nov 26, 2016):

1 First of all I wanna say that I don't have a Linux system (except a router and an android phone), I'm just looking for replacements for the software I use in Windows to understand if I can migrate, so I haven't tested the idea.

2

malware in a sandbox executes firefox or any other program, that program will be inside the sandbox as well. I don't understand how you even got the idea.

I have read the FAQ. There is a question in it

Firefox doesn’t open in a new sandbox. Instead, it opens a new tab in an existing Firefox instance.

and the answer

By default, Firefox browser uses a single process to handle multiple windows. When you start the browser, if another Firefox process is already running, the existing process opens a new tab or a new window. Make sure Firefox is not already running when you start it in Firejail sandbox.

Let we have a sandbox with no network access and want to run a malware in it safely and we have a Firefox open out of sandbox. We run a malware, malware runs firefox with a malicious URI as the first argument, firefox checkes if it is already running using IPC, finds it is and sends a command to a running instance, which is outside of sandbox, to open a malicious URI. This way the malware have exfiltrated data bypassing sandbox restrictions. The page can contain an exploit for some zeroday rce vulns. This way the malware have escaped the sandbox.
Am I right? Or is that item of FAQ obsolete?

<!-- gh-comment-id:263083324 --> @KOLANICH commented on GitHub (Nov 26, 2016): 1 First of all I wanna say that I don't have a Linux system (except a router and an android phone), I'm just looking for replacements for the software I use in Windows to understand if I can migrate, so I haven't tested the idea. 2 >malware in a sandbox executes firefox or any other program, that program will be inside the sandbox as well. I don't understand how you even got the idea. I have read the FAQ. There is a question in it >Firefox doesn’t open in a new sandbox. Instead, it opens a new tab in an existing Firefox instance. and the answer >By default, Firefox browser uses a single process to handle multiple windows. When you start the browser, if another Firefox process is already running, the existing process opens a new tab or a new window. Make sure Firefox is not already running when you start it in Firejail sandbox. Let we have a sandbox with no network access and want to run a malware in it safely and we have a Firefox open out of sandbox. We run a malware, malware runs firefox with a malicious URI as the first argument, firefox checkes if it is already running using IPC, finds it is and sends a command to a running instance, which is outside of sandbox, to open a malicious URI. This way the malware have exfiltrated data bypassing sandbox restrictions. The page can contain an exploit for some zeroday rce vulns. This way the malware have escaped the sandbox. Am I right? Or is that item of FAQ obsolete?
Author
Owner

@0xBRM commented on GitHub (Nov 26, 2016):

That just means IF firefox is ALREADY running (normally), that you won't be able to start a sandbox as the new firefox session will just append itself to the main, already running process. Programs launched from a sandbox stay there. My previous post confirms it. The FAQ is correct, but your interpretation wasn't.

<!-- gh-comment-id:263084116 --> @0xBRM commented on GitHub (Nov 26, 2016): That just means IF firefox is ALREADY running (normally), that you won't be able to start a sandbox as the new firefox session will just append itself to the main, already running process. Programs launched from a sandbox stay there. My previous post confirms it. The FAQ is correct, but your interpretation wasn't.
Author
Owner

@KOLANICH commented on GitHub (Nov 26, 2016):

That just means IF firefox is ALREADY running (normally), that you won't be able to start a sandbox as the new firefox session will just append itself to the main, already running process.

Which means that sandboxed firefox can communicate to unsandboxed one. Which means IPC is not enough isolated. In SandboxIE you can run a firefox in one sandbox, one firefox in another and a firefox unsandboxed and they won't interfere with each other because of IPC isolation (in fact it is/was not as good, as it should be, because at least named pipes (I haven't checked other kernel objects) of sandboxed apps are/were just prefixed by the word "sandboxie" and the name of the sandbox. Surely it is/was a bug because it is possible to setup which IPC should not be isolated in the settings).

<!-- gh-comment-id:263084905 --> @KOLANICH commented on GitHub (Nov 26, 2016): >That just means IF firefox is ALREADY running (normally), that you won't be able to start a sandbox as the new firefox session will just append itself to the main, already running process. Which means that sandboxed firefox can communicate to unsandboxed one. Which means IPC is not enough isolated. In SandboxIE you can run a firefox in one sandbox, one firefox in another and a firefox unsandboxed and they won't interfere with each other because of IPC isolation (in fact it is/was not as good, as it should be, because at least named pipes (I haven't checked other kernel objects) of sandboxed apps are/were just prefixed by the word "sandboxie" and the name of the sandbox. Surely it is/was a bug because it is possible to setup which IPC should not be isolated in the settings).
Author
Owner

@0xBRM commented on GitHub (Nov 26, 2016):

I think --ipc-namespace does what you want, since it creates a new namespace.

<!-- gh-comment-id:263088888 --> @0xBRM commented on GitHub (Nov 26, 2016): I think ```--ipc-namespace``` does what you want, since it creates a new namespace.
Author
Owner

@valoq commented on GitHub (Nov 27, 2016):

If your goal is to run malware in a sandbox, both firejail and sandboxie are the wrong choice. Like most sandbox applications they are build to run normal applications in a environment that reduces the risk and consequences of malware execution. They are not designed to completely isolate from the system, that would defeat the purpose of running normal applications in them that have to communicate in some way to the rest of the system.

Running malware inside them is like putting a seatbelt on and driving into a wall with high speed, expecting not to get hurt.

<!-- gh-comment-id:263111971 --> @valoq commented on GitHub (Nov 27, 2016): If your goal is to run malware in a sandbox, both firejail and sandboxie are the wrong choice. Like most sandbox applications they are build to run normal applications in a environment that reduces the risk and consequences of malware execution. They are not designed to completely isolate from the system, that would defeat the purpose of running normal applications in them that have to communicate in some way to the rest of the system. Running malware inside them is like putting a seatbelt on and driving into a wall with high speed, expecting not to get hurt.
Author
Owner

@KOLANICH commented on GitHub (Nov 27, 2016):

Thank you, but I know. Qubes OS is too resource-hungry for my PC, so sandboxes are better than nothing.

They are not designed to completely isolate from the system, that would defeat the purpose of running normal applications in them that have to communicate in some way to the rest of the system.

It's true. Their purpose is not to isolate completely, but to isolate in a controlled way, allowing the API not threatening security (it's up to user to decide what is a threat according to his threat model and what is not). Hypervisors have the same purpose but work on lower level allowing to run untrusted code in ring 0. Ideal sandbox and an ideal vulnerability-free kernel and drivers are as secure as a separate kernel in an ideal hypervisor if you run only userland code. But there is no anything ideal.

<!-- gh-comment-id:263122957 --> @KOLANICH commented on GitHub (Nov 27, 2016): Thank you, but I know. Qubes OS is too resource-hungry for my PC, so sandboxes are better than nothing. >They are not designed to completely isolate from the system, that would defeat the purpose of running normal applications in them that have to communicate in some way to the rest of the system. It's true. Their purpose is not to isolate completely, but to isolate in a controlled way, allowing the API not threatening security (it's up to user to decide what is a threat according to his threat model and what is not). Hypervisors have the same purpose but work on lower level allowing to run untrusted code in ring 0. Ideal sandbox and an ideal vulnerability-free kernel and drivers are as secure as a separate kernel in an ideal hypervisor if you run only userland code. But there is no anything ideal.
Author
Owner

@netblue30 commented on GitHub (Nov 27, 2016):

Firefox uses a different ipc mechanism, not covered by --ipc-namespace. So far I couldn't figure out what that mechanism is.

<!-- gh-comment-id:263123815 --> @netblue30 commented on GitHub (Nov 27, 2016): Firefox uses a different ipc mechanism, not covered by --ipc-namespace. So far I couldn't figure out what that mechanism is.
Author
Owner

@valoq commented on GitHub (Nov 27, 2016):

@netblue30
This looks interesting https://developer.mozilla.org/en-US/docs/Mozilla/IPDL

@KOLANICH
You don't need Qubes OS. There are several container solutions that can be used for this kind of testing.
Also I would like to point out, that Hypervisors have less attack surface by far.

<!-- gh-comment-id:263127212 --> @valoq commented on GitHub (Nov 27, 2016): @netblue30 This looks interesting https://developer.mozilla.org/en-US/docs/Mozilla/IPDL @KOLANICH You don't need Qubes OS. There are several container solutions that can be used for this kind of testing. Also I would like to point out, that Hypervisors have less attack surface by far.
Author
Owner

@KOLANICH commented on GitHub (Nov 27, 2016):

You don't need Qubes OS. There are several container solutions that can be used for this kind of testing.

In fact I'm not testing. I create a sandhox per app, install apps into sandboxes and use them from them. But sometimes the apps have some malicious functionality. Is firejail what I need?

Firefox uses a different ipc mechanism, not covered by --ipc-namespace. So far I couldn't figure out what that mechanism is.

https://dxr.mozilla.org/mozilla-beta/source/toolkit/xre/nsAppRunner.cpp
https://dxr.mozilla.org/mozilla-beta/source/widget/xremoteclient/XRemoteClient.cpp

It seems it uses x11 for that somehow

<!-- gh-comment-id:263130156 --> @KOLANICH commented on GitHub (Nov 27, 2016): >You don't need Qubes OS. There are several container solutions that can be used for this kind of testing. In fact I'm not testing. I create a sandhox per app, install apps into sandboxes and use them from them. But sometimes the apps have some malicious functionality. Is firejail what I need? >Firefox uses a different ipc mechanism, not covered by --ipc-namespace. So far I couldn't figure out what that mechanism is. https://dxr.mozilla.org/mozilla-beta/source/toolkit/xre/nsAppRunner.cpp https://dxr.mozilla.org/mozilla-beta/source/widget/xremoteclient/XRemoteClient.cpp It seems it uses x11 for that somehow
Author
Owner

@xahare commented on GitHub (Nov 27, 2016):

@KOLANICH im running qubes-os on a 2010 laptop with 8gigs. not the fastest, but still good enough to watch youtube in full screen. on that laptop, firejail is more for access control than compartmentalization.

@netblue30 ive been running separate instances of firefox and chrome in private home dirs with their own network namespace, xephyr and openbox. (xpra is too buggy) no sign of cross contamination.

<!-- gh-comment-id:263152444 --> @xahare commented on GitHub (Nov 27, 2016): @KOLANICH im running qubes-os on a 2010 laptop with 8gigs. not the fastest, but still good enough to watch youtube in full screen. on that laptop, firejail is more for access control than compartmentalization. @netblue30 ive been running separate instances of firefox and chrome in private home dirs with their own network namespace, xephyr and openbox. (xpra is too buggy) no sign of cross contamination.
Author
Owner

@netblue30 commented on GitHub (Nov 28, 2016):

@xahare
Actually as long as you have different ~/.mozilla directories you can run multiple browsers.

@valoq
Thanks for the link.

<!-- gh-comment-id:263303336 --> @netblue30 commented on GitHub (Nov 28, 2016): @xahare Actually as long as you have different ~/.mozilla directories you can run multiple browsers. @valoq Thanks for the link.
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#642
No description provided.