[GH-ISSUE #330] firejail massive breach? Or just a missuse case?

gitea-mirror commented

2026-05-05 05:22:32 -06:00

Owner

Originally created by @ghost on GitHub (Feb 28, 2016).
Original GitHub issue: https://github.com/netblue30/firejail/issues/330

I have two Firefox'es that I use: One is with:

firejail firefox

and the other with:

firejail --private firefox -no-remote

Today I noticed that I could see my normal /home through the second firefox, and this isn't supposed to happen, right?

I recorded a video so you can see. I can't upload it to Youtube because I use the "private" firefox for Youtube, but I uploaded it to sendspace instead. It's only 13 MB. https://www.sendspace.com/file/zrjep9

Originally created by @ghost on GitHub (Feb 28, 2016). Original GitHub issue: https://github.com/netblue30/firejail/issues/330 I have two Firefox'es that I use: One is with: > firejail firefox and the other with: > firejail --private firefox -no-remote Today I noticed that I could see my normal /home through the second firefox, and this isn't supposed to happen, right? I recorded a video so you can see. I can't upload it to Youtube because I use the "private" firefox for Youtube, but I uploaded it to sendspace instead. It's only 13 MB. https://www.sendspace.com/file/zrjep9

gitea-mirror

2026-05-05 05:22:32 -06:00

closed this issue
added the
information_old
label

gitea-mirror commented

2026-05-05 05:22:38 -06:00

Author

Owner

@sinkuu commented on GitHub (Feb 28, 2016):

I can't see my /home from the second firefox with firejaill-0.9.39 (git master).

@sinkuu commented on GitHub (Feb 28, 2016): I can't see my /home from the second firefox with firejaill-0.9.39 (git master).

gitea-mirror commented

2026-05-05 05:22:39 -06:00

Author

Owner

@ghost commented on GitHub (Feb 28, 2016):

I'm using 0.9.38. Is the git version stable enough for day-to-day use?

@ghost commented on GitHub (Feb 28, 2016): I'm using 0.9.38. Is the git version stable enough for day-to-day use?

gitea-mirror commented

2026-05-05 05:22:43 -06:00

Author

Owner

@sinkuu commented on GitHub (Feb 28, 2016):

I downgraded to 0.9.38 but still my home directory is correctly inaccessible. Upgrading to git version may not fix your problem...

Is the git version stable enough for day-to-day use?

I haven't encountered any issue, however my usage is basic (mostly sandboxing firefox with the default profile).

@sinkuu commented on GitHub (Feb 28, 2016): I downgraded to 0.9.38 but still my home directory is correctly inaccessible. Upgrading to git version may not fix your problem... > Is the git version stable enough for day-to-day use? I haven't encountered any issue, however my usage is basic (mostly sandboxing firefox with the default profile).

gitea-mirror commented

2026-05-05 05:22:47 -06:00

Author

Owner

@chiraag-nataraj commented on GitHub (Feb 28, 2016):

I just tested this and I can't see my original home directory from the new Firefox instance. Then again, I have a highly restrictive profile:

# Blacklist/Whitelist

blacklist /usr/local/bin
blacklist /usr/local/sbin

whitelist ${HOME}/.mozilla
whitelist ${HOME}/Downloads/
whitelist ${HOME}/.pulse/
whitelist ${HOME}/.config/pulse/
whitelist ${HOME}/.config/gtk-3.0/
whitelist ${HOME}/.config/google-googletalkplugin/
whitelist ${HOME}/.gtkrc-2.0
whitelist ${HOME}/.gtkrc.mine
whitelist ${HOME}/.Xauthority

# Private directories

private-bin firefox.real,firefox,which,sh
private-etc hosts,passwd,mime.types,fonts/,mailcap,iceweasel/,xdg/,gtk-3.0/,resolv.conf,X11/,pulse/,adobe/,gcrypt/,alternatives/
private-tmp

# Miscellaneous options

shell none
seccomp
noroot
caps.drop all
protocol unix,inet,inet6

So maybe it's one of those options that's masking this issue if it exists?

@chiraag-nataraj commented on GitHub (Feb 28, 2016): I just tested this and I can't see my original home directory from the new Firefox instance. Then again, I have a _highly_ restrictive profile: ``` # Blacklist/Whitelist blacklist /usr/local/bin blacklist /usr/local/sbin whitelist ${HOME}/.mozilla whitelist ${HOME}/Downloads/ whitelist ${HOME}/.pulse/ whitelist ${HOME}/.config/pulse/ whitelist ${HOME}/.config/gtk-3.0/ whitelist ${HOME}/.config/google-googletalkplugin/ whitelist ${HOME}/.gtkrc-2.0 whitelist ${HOME}/.gtkrc.mine whitelist ${HOME}/.Xauthority # Private directories private-bin firefox.real,firefox,which,sh private-etc hosts,passwd,mime.types,fonts/,mailcap,iceweasel/,xdg/,gtk-3.0/,resolv.conf,X11/,pulse/,adobe/,gcrypt/,alternatives/ private-tmp # Miscellaneous options shell none seccomp noroot caps.drop all protocol unix,inet,inet6 ``` So maybe it's one of those options that's masking this issue if it exists?

gitea-mirror commented

2026-05-05 05:22:49 -06:00

Author

Owner

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

It is a Mozilla Firefox problem. This is the easiest way to reproduce it:

(1) Open a sandbox: firejail --private firefox -no-remote

(2) In URL bar type "/home/username" (replace username). The browser displays the content of your private home directory.

(3) In a new tab type "about:support" and click "Open Directory" button. This opens your file manager (whatever is installed by your desktop environment). Navigate to /home/username in file manager. It displays the content of your real home directory, not the sandboxed home directory as in (2).

The file manager started by Firefox talks over a socket to another file manager instance running outside the sandbox. The instance outside the sandbox opens the window. It is not a security problem, but it will confuse the user regarding downloaded files - the files always end up in the sandboxed filesystem. Always check files and directories using the URL bar of the browser.

By default, a desktop environment always starts a file manager when the user logged in. This instance handles all file accesses, subsequent file manager instances just send messages over some socket.

@netblue30 commented on GitHub (Feb 28, 2016): It is a Mozilla Firefox problem. This is the easiest way to reproduce it: (1) Open a sandbox: firejail --private firefox -no-remote (2) In URL bar type "/home/username" (replace username). The browser displays the content of your private home directory. (3) In a new tab type "about:support" and click "Open Directory" button. This opens your file manager (whatever is installed by your desktop environment). Navigate to /home/username in file manager. It displays the content of your real home directory, not the sandboxed home directory as in (2). The file manager started by Firefox talks over a socket to another file manager instance running outside the sandbox. The instance outside the sandbox opens the window. It is not a security problem, but it will confuse the user regarding downloaded files - the files always end up in the sandboxed filesystem. Always check files and directories using the URL bar of the browser. By default, a desktop environment always starts a file manager when the user logged in. This instance handles all file accesses, subsequent file manager instances just send messages over some socket.

gitea-mirror commented

2026-05-05 05:22:53 -06:00

Author

Owner

@chiraag-nataraj commented on GitHub (Feb 28, 2016):

That would explain why I did not have this issue - I run AwesomeWM, not a desktop environment. I also don't have any standalone graphical file browsers installed :D This is certainly an interesting problem. Is there any way to force firefox to open its own dialog as it does on my system instead of relying on the default file manager?

@chiraag-nataraj commented on GitHub (Feb 28, 2016): That would explain why I did not have this issue - I run AwesomeWM, not a desktop environment. I also don't have any standalone graphical file browsers installed :D This is certainly an interesting problem. Is there any way to force firefox to open its own dialog as it does on my system instead of relying on the default file manager?

gitea-mirror commented

2026-05-05 05:22:54 -06:00

Author

Owner

@chiraag-nataraj commented on GitHub (Feb 28, 2016):

Another option would be to see if you can force Nautilus or whatever the default file manager is to open a new instance every time (probably more doable than my first suggestion).

@chiraag-nataraj commented on GitHub (Feb 28, 2016): Another option would be to see if you can force Nautilus or whatever the default file manager is to open a new instance every time (probably more doable than my first suggestion).

gitea-mirror commented

2026-05-05 05:22:58 -06:00

Author

Owner

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

In LXDE I blacklisted the file manager socket . Now, when I click on "Open Directory" the file manager (pcmanfm) crashes. I guess the more we fix it, the more we break it!

@netblue30 commented on GitHub (Feb 28, 2016): In LXDE I blacklisted the file manager socket . Now, when I click on "Open Directory" the file manager (pcmanfm) crashes. I guess the more we fix it, the more we break it!

gitea-mirror commented

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

Author

Owner

@chiraag-nataraj commented on GitHub (Feb 28, 2016):

Yeah this should probably be done on the file manager end haha :P

@chiraag-nataraj commented on GitHub (Feb 28, 2016): Yeah this should probably be done on the file manager end haha :P

gitea-mirror commented

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

Author

Owner

@chiraag-nataraj commented on GitHub (Feb 28, 2016):

There is, of course, the simple solution: don't run a file manager daemon! ;)

@chiraag-nataraj commented on GitHub (Feb 28, 2016): There is, of course, the simple solution: don't run a file manager daemon! ;)

gitea-mirror commented

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

Author

Owner

@ghost commented on GitHub (Feb 29, 2016):

@sinkuu

I downgraded to 0.9.38 but still my home directory is correctly inaccessible

What desktop environment are you using?

@netblue30

The file manager started by Firefox talks over a socket to another file manager instance running outside the sandbox

But why does this happen? Anything opened by a sandbox should also be sandboxed. I wouldn't mind if the sandboxed Firefox started a sandboxed socket, if that's possible.

the files always end up in the sandboxed filesystem

Not according to my video. For instance, I use the private Firefox for Facebook. I downloaded a photo, which should be in the private home, but when I tried uploading this photo to facebook it was like if I was inside my real home, there was no photo from facebook there, only my real files.

@chiraag-nataraj

There is, of course, the simple solution: don't run a file manager daemon! ;)

But KDE is the only DE that works 100% to my needs, in openSUSE. All of the others have serious issues.

@ghost commented on GitHub (Feb 29, 2016): @sinkuu > I downgraded to 0.9.38 but still my home directory is correctly inaccessible What desktop environment are you using? @netblue30 > The file manager started by Firefox talks over a socket to another file manager instance running outside the sandbox But why does this happen? Anything opened by a sandbox should also be sandboxed. I wouldn't mind if the sandboxed Firefox started a sandboxed socket, if that's possible. > the files always end up in the sandboxed filesystem Not according to my video. For instance, I use the private Firefox for Facebook. I downloaded a photo, which should be in the private home, but when I tried uploading this photo to facebook it was like if I was inside my real home, there was no photo from facebook there, only my real files. @chiraag-nataraj > There is, of course, the simple solution: don't run a file manager daemon! ;) But KDE is the only DE that works 100% to my needs, in openSUSE. All of the others have serious issues.

gitea-mirror commented

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

Author

Owner

@chiraag-nataraj commented on GitHub (Feb 29, 2016):

@amarildojr

But KDE is the only DE that works 100% to my needs, in openSUSE. All of the others have serious issues.
I know…it was a joke ;)
But why does this happen? Anything opened by a sandbox should also be sandboxed. I wouldn't mind if the sandboxed Firefox started a sandboxed socket, if that's possible.

It happens because the file manager is already running by the time you start firefox. According to @netblue30, blacklisting the existing socket crashes the file manager. I would look for a way to launch different PcManFM windows with different processes - that may solve this problem?

@chiraag-nataraj commented on GitHub (Feb 29, 2016): @amarildojr > But KDE is the only DE that works 100% to my needs, in openSUSE. All of the others have serious issues. > I know…it was a joke ;) > But why does this happen? Anything opened by a sandbox should also be sandboxed. I wouldn't mind if the sandboxed Firefox started a sandboxed socket, if that's possible. It happens because the file manager is already running by the time you start firefox. According to @netblue30, blacklisting the existing socket crashes the file manager. I would look for a way to launch different PcManFM windows with different processes - that may solve this problem?

gitea-mirror commented

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

Author

Owner

@netblue30 commented on GitHub (Mar 1, 2016):

@amarildojr

You can always check with the Linux kernel what filesystem a process is seeing. The directory is accessible in /proc//root. Start with a "firejail --tree"

$ firejail --tree
20254:netblue:firejail /usr/lib/iceweasel/iceweasel -no-remote 
  20255:netblue:firejail /usr/lib/iceweasel/iceweasel -no-remote 
    20256:netblue:/usr/lib/iceweasel/iceweasel -no-remote 
      20326:netblue:/usr/lib/iceweasel/plugin-container -greomni /usr/lib/iceweasel

For 20255, 20256, and 20326 you should see the same thing in /proc/PID/root/ (do: sudo ls -al /proc/20255/root/home/username for all processes inside the sandbox). In my example here (LXDE) the filemanager window is not even in the sandbox, but I can see it on the screen. Don't trust filemanager windows started from firefox.

@netblue30 commented on GitHub (Mar 1, 2016): @amarildojr You can always check with the Linux kernel what filesystem a process is seeing. The directory is accessible in /proc/<PID>/root. Start with a "firejail --tree" ``` $ firejail --tree 20254:netblue:firejail /usr/lib/iceweasel/iceweasel -no-remote 20255:netblue:firejail /usr/lib/iceweasel/iceweasel -no-remote 20256:netblue:/usr/lib/iceweasel/iceweasel -no-remote 20326:netblue:/usr/lib/iceweasel/plugin-container -greomni /usr/lib/iceweasel ``` For 20255, 20256, and 20326 you should see the same thing in /proc/PID/root/ (do: sudo ls -al /proc/20255/root/home/username for all processes inside the sandbox). In my example here (LXDE) the filemanager window is not even in the sandbox, but I can see it on the screen. Don't trust filemanager windows started from firefox.

gitea-mirror commented

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

Author

Owner

@ghost commented on GitHub (Mar 1, 2016):

MATE also works fine, but only on Debian.

root@amarildo:~# firejail --tree
2041:amarildo:firejail iceweasel
2044:amarildo:firejail iceweasel
2045:amarildo:iceweasel
2189:amarildo:firejail --private iceweasel -no-remote
2192:amarildo:firejail --private iceweasel -no-remote
2193:amarildo:iceweasel -no-remote

I'm not sure I'll stay here, though. I'll probably go back to Arch, but then again, Arch has the same KDE Plasma 5 as openSUSE.

We'll see how it goes.

Don't trust filemanager windows started from firefox

Why not? If it can see the filenames I have, so would an attacker.

@ghost commented on GitHub (Mar 1, 2016): MATE also works fine, but only on Debian. > root@amarildo:~# firejail --tree > 2041:amarildo:firejail iceweasel > 2044:amarildo:firejail iceweasel > 2045:amarildo:iceweasel > 2189:amarildo:firejail --private iceweasel -no-remote > 2192:amarildo:firejail --private iceweasel -no-remote > 2193:amarildo:iceweasel -no-remote I'm not sure I'll stay here, though. I'll probably go back to Arch, but then again, Arch has the same KDE Plasma 5 as openSUSE. We'll see how it goes. > Don't trust filemanager windows started from firefox Why not? If it can see the filenames I have, so would an attacker.

gitea-mirror commented

2026-05-05 05:23:10 -06:00

Author

Owner

@chiraag-nataraj commented on GitHub (Mar 1, 2016):

I'm curious - what happens if you actually try opening one of those files? Does it actually load or does it fail with EPERM or something similar to that?

@chiraag-nataraj commented on GitHub (Mar 1, 2016): I'm curious - what happens if you actually try opening one of those files? Does it actually load or does it fail with EPERM or something similar to that?

gitea-mirror commented

2026-05-05 05:23:12 -06:00

Author

Owner

@netblue30 commented on GitHub (Mar 2, 2016):

Why not? If it can see the filenames I have, so would an attacker.

No, the attacker would not see the files because he doesn't have access to your display, your keyboard and your mouse.

@netblue30 commented on GitHub (Mar 2, 2016): > Why not? If it can see the filenames I have, so would an attacker. No, the attacker would not see the files because he doesn't have access to your display, your keyboard and your mouse.

gitea-mirror commented

2026-05-05 05:23:13 -06:00

Author

Owner

@curiosity-seeker commented on GitHub (Mar 12, 2016):

@netblue30 : Sorry for my ignorance - but could you, please, give a more detailed answer why this is not a security issue? I must admit that I don't understand the technical background of the remark in your last post above. I think understanding this is very important for all Firejail users.

@curiosity-seeker commented on GitHub (Mar 12, 2016): @netblue30 : Sorry for my ignorance - but could you, please, give a more detailed answer why this is not a security issue? I must admit that I don't understand the technical background of the remark in your last post above. I think understanding this is very important for all Firejail users.

gitea-mirror commented

2026-05-05 05:23:16 -06:00

Author

Owner

@chiraag-nataraj commented on GitHub (Mar 12, 2016):

@amarildojr: I'm curious as to what happens if you try to open one of the files in your real home directory.

@chiraag-nataraj commented on GitHub (Mar 12, 2016): @amarildojr: I'm curious as to what happens if you try to open one of the files in your real home directory.

gitea-mirror commented

2026-05-05 05:23:17 -06:00

Author

Owner

@chiraag-nataraj commented on GitHub (Mar 12, 2016):

@curiosity-seeker: I think this is what @netblue30 means. The thing is that firefox doesn't actually have access to those files (or at least it shouldn't). However, since it connects to a file manager socket that exists outside of the jail, it appears that you can access those files.

@chiraag-nataraj commented on GitHub (Mar 12, 2016): @curiosity-seeker: I _think_ this is what @netblue30 means. The thing is that firefox doesn't actually have access to those files (or at least it shouldn't). _However_, since it connects to a file manager socket that exists outside of the jail, it appears that you _can_ access those files.

gitea-mirror commented

2026-05-05 05:23:19 -06:00

Author

Owner

@curiosity-seeker commented on GitHub (Mar 13, 2016):

@chiraag-nataraj : Thanks for your reply! I agree that Firefox doesn't have access to those files which are not whitelisted. The question is if an attacker would be able to start the file manager via about:support and use that to see/manipulate any folders/files outside the sandbox. I don't understand yet why this is impossible for an attacker according to @netblue30 .

@curiosity-seeker commented on GitHub (Mar 13, 2016): @chiraag-nataraj : Thanks for your reply! I agree that Firefox doesn't have access to those files which are not whitelisted. The question is if an attacker would be able to start the file manager via about:support and use that to see/manipulate any folders/files outside the sandbox. I don't understand yet why this is impossible for an attacker according to @netblue30 .

gitea-mirror commented

2026-05-05 05:23:20 -06:00

Author

Owner

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

@curiosity-seeker

Firefox cannot access and manipulate the memory of the process running outside the sandbox. It can only send messages over TCP/IP or UNIX sockets. In this case it sends a message to an existing file manager process over a UNIX/DBus socket. It is no different than sending messages over to PulseAudio or X11 socket.

@netblue30 commented on GitHub (Mar 13, 2016): @curiosity-seeker Firefox cannot access and manipulate the memory of the process running outside the sandbox. It can only send messages over TCP/IP or UNIX sockets. In this case it sends a message to an existing file manager process over a UNIX/DBus socket. It is no different than sending messages over to PulseAudio or X11 socket.

gitea-mirror commented

2026-05-05 05:23:22 -06:00

Author

Owner

@curiosity-seeker commented on GitHub (Mar 13, 2016):

@netblue30 : Thank very much! I'm beginning to understand ;-)

@curiosity-seeker commented on GitHub (Mar 13, 2016): @netblue30 : Thank very much! I'm beginning to understand ;-)

gitea-mirror commented

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

Author

Owner

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

Sorry for being stubborn! I'm running Fedora 23 with KDE Plasma 5 in a Virtualbox VM and Firejail 0.9.38. firejail --tree gives:

2376:hank:/usr/bin/firejail /usr/bin/firefox
  2377:hank:/usr/bin/firejail /usr/bin/firefox
    2378:hank:/usr/lib64/firefox/firefox

After going to about:support and clicking "Open directory", Dolphin starts. firejail --tree now shows this:

2376:hank:/usr/bin/firejail /usr/bin/firefox
  2377:hank:/usr/bin/firejail /usr/bin/firefox
    2378:hank:/usr/lib64/firefox/firefox
    2711:hank:dolphin /home/hank/.mozilla/firefox/pis8b7bb.default

It seems that Dolphin is started within the sandbox. Doesn't that contradict what you said above?

However, Dolphin doesn't show up if I enter sudo ls -al /proc/2377/root/home/hank

I'm confused.

@curiosity-seeker commented on GitHub (Mar 14, 2016): Sorry for being stubborn! I'm running Fedora 23 with KDE Plasma 5 in a Virtualbox VM and Firejail 0.9.38. _firejail --tree_ gives: ``` 2376:hank:/usr/bin/firejail /usr/bin/firefox 2377:hank:/usr/bin/firejail /usr/bin/firefox 2378:hank:/usr/lib64/firefox/firefox ``` After going to about:support and clicking "Open directory", Dolphin starts. _firejail --tree_ now shows this: ``` 2376:hank:/usr/bin/firejail /usr/bin/firefox 2377:hank:/usr/bin/firejail /usr/bin/firefox 2378:hank:/usr/lib64/firefox/firefox 2711:hank:dolphin /home/hank/.mozilla/firefox/pis8b7bb.default ``` It seems that Dolphin is started within the sandbox. Doesn't that contradict what you said above? However, Dolphin doesn't show up if I enter sudo ls -al /proc/2377/root/home/hank I'm confused.

gitea-mirror commented

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

Author

Owner

@ghost commented on GitHub (Mar 14, 2016):

@chiraag-nataraj

I'm curious as to what happens if you try to open one of the files in your real home directory.

I could see the files in openSUSE, but not on Arch. It seems Arch's KDE5 is working normally.

@ghost commented on GitHub (Mar 14, 2016): @chiraag-nataraj > I'm curious as to what happens if you try to open one of the files in your real home directory. I could see the files in openSUSE, but not on Arch. It seems Arch's KDE5 is working normally.

gitea-mirror commented

2026-05-05 05:23:30 -06:00

Author

Owner

@curiosity-seeker commented on GitHub (Mar 15, 2016):

I got the same result as on Fedora on Manjaro (Arch based) with Plasma 5 after Dolphin was launched from about:support:

16778:hank:/usr/bin/firejail firefox 
  16779:hank:/usr/bin/firejail firefox 
    16780:hank:firefox 
      16812:hank:/usr/lib/mozilla/kmozillahelper 
      16911:hank:/usr/lib/firefox/plugin-container -greomni /usr/lib/firefox/omni.ja -appomni /usr/lib/firefox/browser/omni.ja -appdir /usr/lib/firefox/browser 2 tab 
        16963:hank:/usr/lib/mozilla/kmozillahelper 
    17318:hank:/usr/bin/dolphin --select /home/hank/.mozilla/firefox/lxt0usza.e10s

So again it seems to me that Dolphin is started within the sandbox.

@curiosity-seeker commented on GitHub (Mar 15, 2016): I got the same result as on Fedora on Manjaro (Arch based) with Plasma 5 after Dolphin was launched from about:support: ``` 16778:hank:/usr/bin/firejail firefox 16779:hank:/usr/bin/firejail firefox 16780:hank:firefox 16812:hank:/usr/lib/mozilla/kmozillahelper 16911:hank:/usr/lib/firefox/plugin-container -greomni /usr/lib/firefox/omni.ja -appomni /usr/lib/firefox/browser/omni.ja -appdir /usr/lib/firefox/browser 2 tab 16963:hank:/usr/lib/mozilla/kmozillahelper 17318:hank:/usr/bin/dolphin --select /home/hank/.mozilla/firefox/lxt0usza.e10s ``` So again it seems to me that Dolphin is started within the sandbox.

gitea-mirror commented

2026-05-05 05:23:32 -06:00

Author

Owner

@netblue30 commented on GitHub (Mar 15, 2016):

I think the file manager always starts inside the sandbox, than if it detects another instance running, it sends the message to the main one. If not, it just shows whatever it finds in the sandbox file system.

@netblue30 commented on GitHub (Mar 15, 2016): I think the file manager always starts inside the sandbox, than if it detects another instance running, it sends the message to the main one. If not, it just shows whatever it finds in the sandbox file system.

gitea-mirror commented

2026-05-05 05:23:34 -06:00

Author

Owner

@curiosity-seeker commented on GitHub (Mar 16, 2016):

I think the file manager always starts inside the sandbox, than if it detects another instance running, it sends the message to the main one. If not, it just shows whatever it finds in the sandbox file system.

Well, another instance of Dolphin was not running. Nevertheless, it shows my complete real file system. Or more exactly: It shows my ~/.mozilla/firefox folder (not only the Firefox profile folder currently used) from where I can go everywhere in the file system.

I've tried it again on Manjaro:

10581:hank:/usr/bin/firejail firefox 
  10582:hank:/usr/bin/firejail firefox 
    10583:hank:firefox 
      10615:hank:/usr/lib/mozilla/kmozillahelper 
      10893:hank:/usr/lib/mozilla/kmozillahelper 
      11362:hank:/usr/lib/firefox/plugin-container -greomni /usr/lib/firefox/omni.ja -appomni /usr/lib/firefox/browser/omni.ja -appdir /usr/lib/firefox/browser 2 tab 
        11395:hank:/usr/lib/mozilla/kmozillahelper 
    19296:hank:/usr/bin/dolphin --select /home/hank/.mozilla/firefox/lxt0usza.e10s

If I chose the tree view in htop I get:

kdeinit5: Running ...
   file.so [kdeinit5] file local:/run/user/1000/klauncherXM6933.1.slave-socket local:/runuser/1000/dolphincSa431.3.slave-socket
   file.so [kdeinit5] file local:/run/user/1000/klauncherXM6933.1.slave-socket local:/runuser/1000/dolphinEab431.1.slave-socket
   /usr/bin/firejail firefox
      /usr/bin/firejail firefox
           /usr/bin/dolphin --select /home/hank/.mozilla/firefox/lxt0szra.e10s
           /usr/bin/dolphin --select /home/hank/.mozilla/firefox/lxt0szra.e10s

Does that help somehow?

@curiosity-seeker commented on GitHub (Mar 16, 2016): > I think the file manager always starts inside the sandbox, than if it detects another instance running, it sends the message to the main one. If not, it just shows whatever it finds in the sandbox file system. Well, another instance of Dolphin was not running. Nevertheless, it shows my complete real file system. Or more exactly: It shows my ~/.mozilla/firefox folder (not only the Firefox profile folder currently used) from where I can go everywhere in the file system. I've tried it again on Manjaro: ``` 10581:hank:/usr/bin/firejail firefox 10582:hank:/usr/bin/firejail firefox 10583:hank:firefox 10615:hank:/usr/lib/mozilla/kmozillahelper 10893:hank:/usr/lib/mozilla/kmozillahelper 11362:hank:/usr/lib/firefox/plugin-container -greomni /usr/lib/firefox/omni.ja -appomni /usr/lib/firefox/browser/omni.ja -appdir /usr/lib/firefox/browser 2 tab 11395:hank:/usr/lib/mozilla/kmozillahelper 19296:hank:/usr/bin/dolphin --select /home/hank/.mozilla/firefox/lxt0usza.e10s ``` If I chose the tree view in htop I get: ``` kdeinit5: Running ... file.so [kdeinit5] file local:/run/user/1000/klauncherXM6933.1.slave-socket local:/runuser/1000/dolphincSa431.3.slave-socket file.so [kdeinit5] file local:/run/user/1000/klauncherXM6933.1.slave-socket local:/runuser/1000/dolphinEab431.1.slave-socket /usr/bin/firejail firefox /usr/bin/firejail firefox /usr/bin/dolphin --select /home/hank/.mozilla/firefox/lxt0szra.e10s /usr/bin/dolphin --select /home/hank/.mozilla/firefox/lxt0szra.e10s ``` Does that help somehow?

gitea-mirror commented

2026-05-05 05:23:35 -06:00

Author

Owner

@netblue30 commented on GitHub (Mar 16, 2016):

If it shows all the file system, it means is running outside the sandbox. You can verify that by looking at what the kernel is reporting as a filesystem in /proc/PID/root - you get there a full copy of the file system for each process. So, in your example above, (as root user) look at /proc/19296/root, it should be the same directory tree as /proc/10583/root.

@netblue30 commented on GitHub (Mar 16, 2016): If it shows all the file system, it means is running outside the sandbox. You can verify that by looking at what the kernel is reporting as a filesystem in /proc/PID/root - you get there a full copy of the file system for each process. So, in your example above, (as root user) look at /proc/19296/root, it should be the same directory tree as /proc/10583/root.

gitea-mirror commented

2026-05-05 05:23:37 -06:00

Author

Owner

@curiosity-seeker commented on GitHub (Mar 17, 2016):

Thanks, I tried it again:

3088:hank:/usr/bin/firejail firefox 
  3089:hank:/usr/bin/firejail firefox 
    3090:hank:firefox 
      3122:hank:/usr/lib/mozilla/kmozillahelper 
      3214:hank:/usr/lib/firefox/plugin-container -greomni /usr/lib/firefox/omni.ja -appomni /usr/lib/firefox/browser/omni.ja -appdir /usr/lib/firefox/browser 2 tab 
        3270:hank:/usr/lib/mozilla/kmozillahelper 
    9494:hank:/usr/bin/dolphin --select /home/hank/.mozilla/firefox/lxt0usza.e10s

sudo ls -al /proc/9494/root shows:

lrwxrwxrwx 1 hank users 0 17. Mär 11:25 /proc/9494/root -> /

And sudo ls -al /proc/3090/root shows:

lrwxrwxrwx 1 hank users 0 17. Mär 11:25 /proc/3090/root -> /

So the directory tree is identical. This confirms what you're saying. However, I must admit that I have problems to interpret what I'm seeing. From my naive understanding, PID 3090 is a sub-process of the firejailed Firefox PID 3089 running within the sandbox. They are showing the same directory tree as sudo ls -al /proc/3089/root gives:

lrwxrwxrwx 1 root root 0 17. Mär 11:26 /proc/3089/root -> /

So why should the fact that PID 9494 shows the same directory tree as PID 3090 (and PID 3089) tell me that Dolphin is running outside the sandbox? I'm very sorry but I don't get it ...

@curiosity-seeker commented on GitHub (Mar 17, 2016): Thanks, I tried it again: ``` 3088:hank:/usr/bin/firejail firefox 3089:hank:/usr/bin/firejail firefox 3090:hank:firefox 3122:hank:/usr/lib/mozilla/kmozillahelper 3214:hank:/usr/lib/firefox/plugin-container -greomni /usr/lib/firefox/omni.ja -appomni /usr/lib/firefox/browser/omni.ja -appdir /usr/lib/firefox/browser 2 tab 3270:hank:/usr/lib/mozilla/kmozillahelper 9494:hank:/usr/bin/dolphin --select /home/hank/.mozilla/firefox/lxt0usza.e10s ``` _sudo ls -al /proc/9494/root_ shows: ``` lrwxrwxrwx 1 hank users 0 17. Mär 11:25 /proc/9494/root -> / ``` And _sudo ls -al /proc/3090/root_ shows: ``` lrwxrwxrwx 1 hank users 0 17. Mär 11:25 /proc/3090/root -> / ``` So the directory tree is identical. This confirms what you're saying. However, I must admit that I have problems to interpret what I'm seeing. From my naive understanding, PID 3090 is a sub-process of the firejailed Firefox PID 3089 running within the sandbox. They are showing the same directory tree as _sudo ls -al /proc/3089/root_ gives: ``` lrwxrwxrwx 1 root root 0 17. Mär 11:26 /proc/3089/root -> / ``` So why should the fact that PID 9494 shows the same directory tree as PID 3090 (and PID 3089) tell me that Dolphin is running outside the sandbox? I'm very sorry but I don't get it ...

gitea-mirror commented

2026-05-05 05:23:39 -06:00

Author

Owner

@netblue30 commented on GitHub (Mar 17, 2016):

In your case 3089, 3090, 3122, 3214, 3270, and 9494 should show the same thing. Go for a directory you recognize as being in the sandbox, for example your home directory:

$ firejail --tree
1196:netblue:firejail --name=browser --net=eth0
  1197:netblue:firejail --name=browser --net=eth0
    1215:netblue:/bin/sh -c "/usr/lib/iceweasel/iceweasel"  
      1216:netblue:/usr/lib/iceweasel/iceweasel 
$ sudo ls -al /proc/1216/root/home/netblue
total 1304
drwxr-xr-x 11 netblue netblue    4096 Jan 22 09:59 .
drwxr-xr-x  3 root    root         60 Mar 17 07:45 ..
dr-x------  2 root    root         40 Mar 17 07:45 .adobe
-rw-------  1 netblue netblue      10 Jan 24 08:54 .asoundrc
-r--------  1 root    root          0 Mar 17 07:45 .bash_history
-rw-r--r--  1 netblue netblue    3515 Dec 25 21:34 .bashrc
-rw-------  1 netblue netblue 1268785 Dec 25 18:06 bookmarks-2.html
drwx------  5 netblue netblue    4096 Dec 25 21:39 .cache
drwx------  4 netblue netblue    4096 Feb 21 16:18 .config
drwxr-xr-x  2 netblue netblue    4096 Dec 25 21:34 Desktop
drwxr-xr-x  6 netblue netblue    4096 Mar 16 23:17 Downloads
drwxr-xr-x  2 netblue netblue    4096 Mar 17 08:14 dwhelper
dr-x------  2 root    root         40 Mar 17 07:45 .macromedia
drwx------  4 netblue netblue    4096 Dec 25 21:34 .mozilla
drwxr-xr-x  3 netblue netblue    4096 Nov  2 16:21 mozloader
-rw-------  1 netblue netblue   23657 Mar 17 07:45 .Xauthority
netblue@debian:~$

It will list all the files. Blacklisted files should show root read-only, for example .bashrc or .macromedia above.

@netblue30 commented on GitHub (Mar 17, 2016): In your case 3089, 3090, 3122, 3214, 3270, and 9494 should show the same thing. Go for a directory you recognize as being in the sandbox, for example your home directory: ``` $ firejail --tree 1196:netblue:firejail --name=browser --net=eth0 1197:netblue:firejail --name=browser --net=eth0 1215:netblue:/bin/sh -c "/usr/lib/iceweasel/iceweasel" 1216:netblue:/usr/lib/iceweasel/iceweasel $ sudo ls -al /proc/1216/root/home/netblue total 1304 drwxr-xr-x 11 netblue netblue 4096 Jan 22 09:59 . drwxr-xr-x 3 root root 60 Mar 17 07:45 .. dr-x------ 2 root root 40 Mar 17 07:45 .adobe -rw------- 1 netblue netblue 10 Jan 24 08:54 .asoundrc -r-------- 1 root root 0 Mar 17 07:45 .bash_history -rw-r--r-- 1 netblue netblue 3515 Dec 25 21:34 .bashrc -rw------- 1 netblue netblue 1268785 Dec 25 18:06 bookmarks-2.html drwx------ 5 netblue netblue 4096 Dec 25 21:39 .cache drwx------ 4 netblue netblue 4096 Feb 21 16:18 .config drwxr-xr-x 2 netblue netblue 4096 Dec 25 21:34 Desktop drwxr-xr-x 6 netblue netblue 4096 Mar 16 23:17 Downloads drwxr-xr-x 2 netblue netblue 4096 Mar 17 08:14 dwhelper dr-x------ 2 root root 40 Mar 17 07:45 .macromedia drwx------ 4 netblue netblue 4096 Dec 25 21:34 .mozilla drwxr-xr-x 3 netblue netblue 4096 Nov 2 16:21 mozloader -rw------- 1 netblue netblue 23657 Mar 17 07:45 .Xauthority netblue@debian:~$ ``` It will list all the files. Blacklisted files should show root read-only, for example .bashrc or .macromedia above.

gitea-mirror commented

2026-05-05 05:23:40 -06:00

Author

Owner

@curiosity-seeker commented on GitHub (Mar 17, 2016):

Ah, yes! I had made a mistake in my previous post. I had only entered

sudo ls -al /proc/PID/root

instead of

sudo ls -al /proc/PID/root/home/hank

Sorry for my confusion! Now with the correct command the relevant PIDs - including the one for Dolphin - show the same items in my home directory.

So the inference is: Since that Dolphin instance launched in about:support shows my real complete file system, it can not be the PID shown with firejail --tree , hence it must be a process outside the sandbox. Is this the right conclusion?

@curiosity-seeker commented on GitHub (Mar 17, 2016): Ah, yes! I had made a mistake in my previous post. I had only entered _sudo ls -al /proc/PID/root_ instead of _sudo ls -al /proc/PID/root/home/hank_ Sorry for my confusion! Now with the correct command the relevant PIDs - including the one for Dolphin - show the same items in my home directory. So the inference is: Since that Dolphin instance launched in about:support shows my real **complete** file system, it can **not** be the PID shown with _firejail --tree_ , hence it **must** be a process outside the sandbox. Is this the right conclusion?

gitea-mirror commented

2026-05-05 05:23:42 -06:00

Author

Owner

@netblue30 commented on GitHub (Mar 20, 2016):

Yes, it should be a process outside the sandbox.

@netblue30 commented on GitHub (Mar 20, 2016): Yes, it should be a process outside the sandbox.

Rows
Columns

[GH-ISSUE #330] firejail massive breach? Or just a missuse case? #232