github-starred/firejail

Fork 0

mirror of https://github.com/netblue30/firejail.git synced 2026-05-15 14:16:14 -06:00

[GH-ISSUE #1261] File Manager Sandboxing #861

New issue

Closed

opened 2026-05-05 06:59:32 -06:00 by gitea-mirror · 5 comments

gitea-mirror commented

2026-05-05 06:59:32 -06:00

Owner

Originally created by @SkewedZeppelin on GitHub (May 3, 2017).
Original GitHub issue: https://github.com/netblue30/firejail/issues/1261

Symlinks for the common file managers are installed in /usr/local/bin by firecfg. File managers are usually started by default at login time, and will be sandboxed. Clicking on a file in the file manager will start the corresponding program in the same sandbox as the file manager. For example, clicking on a video file will start a sandboxed VLC running the video.

Does that not defeat the purpose of Firejail? Any sandboxed program spawned under an already existing sandbox will not have its profile set, correct? So then won't that give programs more permissions then they'd normally have? And at the same time falsely leading users to believe that their apps are sandboxed?

For example gedit has 'net none', but if you open up a txt file from within Thunar, it'll end up with networking access. This issue becomes even worse when you end up spawning an application with a whitelist only profile which then ends up with full access to your files. Demonstration here: https://gist.github.com/SpotComms/55c8372cef381439cd9a90476e175f93

This point was clearly brought up in #1178 so I don't understand how this happened.

Originally created by @SkewedZeppelin on GitHub (May 3, 2017). Original GitHub issue: https://github.com/netblue30/firejail/issues/1261 > Symlinks for the common file managers are installed in /usr/local/bin by firecfg. File managers are usually started by default at login time, and will be sandboxed. Clicking on a file in the file manager will start the corresponding program in the same sandbox as the file manager. For example, clicking on a video file will start a sandboxed VLC running the video. Does that not defeat the purpose of Firejail? Any sandboxed program spawned under an already existing sandbox will not have its profile set, correct? So then won't that give programs more permissions then they'd normally have? And at the same time falsely leading users to believe that their apps are sandboxed? For example gedit has 'net none', but if you open up a txt file from within Thunar, it'll end up with networking access. This issue becomes even worse when you end up spawning an application with a whitelist only profile which then ends up with full access to your files. Demonstration here: https://gist.github.com/SpotComms/55c8372cef381439cd9a90476e175f93 This point was clearly brought up in #1178 so I don't understand how this happened.

gitea-mirror

2026-05-05 06:59:32 -06:00

closed this issue
added the
enhancement
label

gitea-mirror commented

2026-05-05 06:59:37 -06:00

Author

Owner

@cryzed commented on GitHub (May 3, 2017):

That is correct, see also #1256, the last 2 comments especially. To quote @netblue30:

Unfortunately that's not possible, the first sandbox will not allow the second sandbox to rise privileges and set up the profile.

If you are really motivated there is a way to work around it: Have one "firejail-launcher" process listening on a socket unsandboxed for incoming requests. Then from within the Sandbox that you want to start, you can configure the opener (xdg-open and variants) using desktop files or using your file manager's file association settings, to instead open the text file using something like: firejail-launcher run gedit. When you then attempt to edit the text file, the firejail-launcher process instead contacts the instance running outside the sandbox and launches gedit with the correct profile and arguments.

I did something like this, but I haven't used it much since, see here (I have since switched to using whitelist in my profiles, so the features related to updating home-prefixes are outdated and need to be removed, in case you are curious). So this Python script has a daemon command (starts the firejail-launcher outside the sandbox) and a run command, which is used from within the sandbox. To contact the daemon, XMLRPC is used. There's also a whitelist feature, so not every process in a firejail sandbox can launch every other process using the launcher -- however this is still incomplete: there's currently no easy way to create specific whitelists for specific sandboxes.

The reason why I haven't actually used it much is, because I don't sandbox my file manager. If I can't trust my file manager, I'd rather be using a different desktop environment, and I reduced potential exploit vectors by disabling file thumbnails completely. Very unlikely that magic is in some way exploitable, since it just reads the first 1024 bytes of a file or so to determine the MIME-type. I also usually have some kind of "bridge" folder in my file system, usually ~/Downloads where most data is shared between my other processes, and they all have access t it.

So I feel your concerns are valid, but they can be worked around if you are motivated enough/willing to put up with some work. I still would like if there was something like the launcher idea directly integrated into firejail -- however I'm also not sure if this is the perfect way to do it, just the one I came up with.

@cryzed commented on GitHub (May 3, 2017): That is correct, see also #1256, the last 2 comments especially. To quote @netblue30: > Unfortunately that's not possible, the first sandbox will not allow the second sandbox to rise privileges and set up the profile. If you are really motivated there is a way to work around it: Have one "firejail-launcher" process listening on a socket unsandboxed for incoming requests. Then from within the Sandbox that you want to start, you can configure the opener (xdg-open and variants) using desktop files or using your file manager's file association settings, to instead open the text file using something like: `firejail-launcher run gedit`. When you then attempt to edit the text file, the firejail-launcher process instead contacts the instance running outside the sandbox and launches gedit with the correct profile and arguments. I did something like this, but I haven't used it much since, see [here](https://gist.github.com/cryzed/1fff0a41309f4555efbb48cf28cd7b65#file-glassbox-py-L356) (I have since switched to using whitelist in my profiles, so the features related to updating home-prefixes are outdated and need to be removed, in case you are curious). So this Python script has a daemon command (starts the firejail-launcher outside the sandbox) and a run command, which is used from within the sandbox. To contact the daemon, XMLRPC is used. There's also a whitelist feature, so not every process in a firejail sandbox can launch every other process using the launcher -- however this is still incomplete: there's currently no easy way to create specific whitelists for specific sandboxes. The reason why I haven't actually used it much is, because I don't sandbox my file manager. If I can't trust my file manager, I'd rather be using a different desktop environment, and I reduced potential exploit vectors by disabling file thumbnails completely. Very unlikely that `magic` is in some way exploitable, since it just reads the first 1024 bytes of a file or so to determine the MIME-type. I also usually have some kind of "bridge" folder in my file system, usually `~/Downloads` where most data is shared between my other processes, and they all have access t it. So I feel your concerns are valid, but they can be worked around if you are motivated enough/willing to put up with some work. I still would like if there was something like the launcher idea directly integrated into firejail -- however I'm also not sure if this is the perfect way to do it, just the one I came up with.

gitea-mirror commented

2026-05-05 06:59:38 -06:00

Author

Owner

@SkewedZeppelin commented on GitHub (May 3, 2017):

Yes, but shouldn't file managers be removed from firecfg for now to at least prevent this escalation? That was my original point, to simply remove them.

@SkewedZeppelin commented on GitHub (May 3, 2017): Yes, but shouldn't file managers be removed from firecfg for now to at least prevent this escalation? That was my original point, to simply remove them.

gitea-mirror commented

2026-05-05 06:59:41 -06:00

Author

Owner

@cryzed commented on GitHub (May 3, 2017):

Oh huh right, I completely missed that. Sorry for going off on a tangent then. Also I agree that firecfg should not create "weak" profile symlinks then.

@cryzed commented on GitHub (May 3, 2017): Oh huh right, I completely missed that. Sorry for going off on a tangent then. Also I agree that firecfg should not create "weak" profile symlinks then.

gitea-mirror commented

2026-05-05 06:59:43 -06:00

Author

Owner

@netblue30 commented on GitHub (May 3, 2017):

Thanks, I removed caja (MATE), nemo (Cinnamon) and thunar (XFCE) from firecfg.config.

In my testing on Debian stable, pcmanfm (LXDE) uses a full path and will not pick up the symbolic link in /usr/local/bin - I am still looking into it.

Dolphin (KDE) has a different architecture, and will always pick up the symbolic link even when dolphin is sandboxed. This means we can bring in a very restrictive setup for Dolphin.

I cannot figure out Gnome. I cannot get even basic functionality like clicking on a pdf file and opening it in a sandbox, regardless what the sandbox profile is. I am on Ubuntu Gnome 17.04, nautilus is there but is not run when the file manager starts.

@SpotComms : the two most important lines in a profile file are "seccomp" and "include /etc/firejail/disable-common.inc". I would say they bring in about 80% of all the security possible. In most cases this is better than nothing.

@cryzed : we try to stay away for bringing in a new daemons. Such a daemon would be very difficult to secure, more difficult than gedit or some other regular program we try to secure in the first place.

I'll keep this open, if you run into problems let me know.

@netblue30 commented on GitHub (May 3, 2017): Thanks, I removed caja (MATE), nemo (Cinnamon) and thunar (XFCE) from firecfg.config. In my testing on Debian stable, pcmanfm (LXDE) uses a full path and will not pick up the symbolic link in /usr/local/bin - I am still looking into it. Dolphin (KDE) has a different architecture, and will always pick up the symbolic link even when dolphin is sandboxed. This means we can bring in a very restrictive setup for Dolphin. I cannot figure out Gnome. I cannot get even basic functionality like clicking on a pdf file and opening it in a sandbox, regardless what the sandbox profile is. I am on Ubuntu Gnome 17.04, nautilus is there but is not run when the file manager starts. @SpotComms : the two most important lines in a profile file are "seccomp" and "include /etc/firejail/disable-common.inc". I would say they bring in about 80% of all the security possible. In most cases this is better than nothing. @cryzed : we try to stay away for bringing in a new daemons. Such a daemon would be very difficult to secure, more difficult than gedit or some other regular program we try to secure in the first place. I'll keep this open, if you run into problems let me know.

gitea-mirror commented

2026-05-05 06:59:44 -06:00

Author

Owner

@netblue30 commented on GitHub (May 9, 2017):

all set, I have support for LXDE and LXQT.

@netblue30 commented on GitHub (May 9, 2017): all set, I have support for LXDE and LXQT.

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#861

No description provided.

Rows
Columns