[GH-ISSUE #1256] More reliable alternative to /usr/local/bin

gitea-mirror commented

2026-05-05 06:59:07 -06:00

Owner

Originally created by @cryzed on GitHub (Apr 29, 2017).
Original GitHub issue: https://github.com/netblue30/firejail/issues/1256

I think there should be a more robust alternative to placing executables/links in /usr/local/bin like firecfg does it currently. I recently noticed that, at least in KDE, when for example using Discord, it is possible to launch unsandboxed applications from the sandboxed environment.

I think this can happen in KDE because Discord attempts to launch the application, the KDE-specific xdg-open is used which contacts the unsandboxed, running kioclient and instructs it to open a desktop file -- in this case for some reason the system-wide *.desktop file located in /usr/share/applications instead of the one located in the user-local ~/.local/share/applications folder. If I close all Firefox instances for example beforehand and then open a link from the sandboxed Discord client, an unsandboxed /usr/lib/firefox/firefox executable is running.

This issue could be completely prevented (I think) by moving or renaming the original executables and then symlinking/creating custom firejail launcher executables that execute the original executables. There would be no easy way to accidentally start an unsandboxed application then. Of course this is more invasive to the system.

Slightly related to this issue: it would be very nice if there was a way for firejail to check if the current launch of an application was started originally from an existing firejail environment and then ideally start the application using its own existing profile. To elaborate a bit on what I mean by that: if I have configured a profile for thunderbird and click on an e-mail address in a different sandboxed application, it would be much nicer if thunderbird was started usings its own profile in a new sandbox, instead of the existing one with its configuration. This would probably have to be done on a whitelist-based approach, to prevent for example untrusted, sandboxed applications without internet access launching applications that are able to transmit data.

Originally created by @cryzed on GitHub (Apr 29, 2017). Original GitHub issue: https://github.com/netblue30/firejail/issues/1256 I think there should be a more robust alternative to placing executables/links in `/usr/local/bin` like [firecfg](https://firejail.wordpress.com/features-3/man-firecfg/) does it currently. I recently noticed that, at least in KDE, when for example using Discord, it is possible to launch unsandboxed applications from the sandboxed environment. I think this can happen in KDE because Discord attempts to launch the application, the KDE-specific `xdg-open` is used which contacts the unsandboxed, running `kioclient` and instructs it to open a desktop file -- in this case for some reason the system-wide *.desktop file located in `/usr/share/applications` instead of the one located in the user-local `~/.local/share/applications` folder. If I close all Firefox instances for example beforehand and then open a link from the sandboxed Discord client, an unsandboxed `/usr/lib/firefox/firefox` executable is running. This issue could be completely prevented (I think) by moving or renaming the original executables and then symlinking/creating custom firejail launcher executables that execute the original executables. There would be no easy way to accidentally start an unsandboxed application then. Of course this is more invasive to the system. Slightly related to this issue: it would be very nice if there was a way for firejail to check if the current launch of an application was started originally from an existing firejail environment and then ideally start the application using its own existing profile. To elaborate a bit on what I mean by that: if I have configured a profile for thunderbird and click on an e-mail address in a different sandboxed application, it would be much nicer if thunderbird was started usings its own profile in a _new_ sandbox, instead of the existing one with its configuration. This would probably have to be done on a whitelist-based approach, to prevent for example untrusted, sandboxed applications without internet access launching applications that _are_ able to transmit data.

gitea-mirror

2026-05-05 06:59:07 -06:00

closed this issue
added the
information_old
label

gitea-mirror commented

2026-05-05 06:59:11 -06:00

Author

Owner

@SkewedZeppelin commented on GitHub (Apr 30, 2017):

On the first part how would packages updates be handled? They'd always be overwriting the shims and then you'd have to rerun firecfg every update. And then I could see a few issues caused by that, already with the /usr/local/bin method rkhunter gets its file integrity feature destroyed for configured applications. And the user always remembering to rerun firecfg is annoying. You could do like what paxd (used to do :( ) but I'm not sure how many people like misc unnecessary daemons running in the background.

And for the last part can't that be done already using 'join-or-start'? But I know what you mean... you open a link in your email client and it spawns a new (broken) Chromium and then even after you close it your original Chromium is janked up.

@SkewedZeppelin commented on GitHub (Apr 30, 2017): On the first part how would packages updates be handled? They'd always be overwriting the shims and then you'd have to rerun firecfg every update. And then I could see a few issues caused by that, already with the /usr/local/bin method rkhunter gets its file integrity feature destroyed for configured applications. And the user always remembering to rerun firecfg is annoying. You could do like what paxd (used to do :( ) but I'm not sure how many people like misc unnecessary daemons running in the background. And for the last part can't that be done already using 'join-or-start'? But I know what you mean... you open a link in your email client and it spawns a new (broken) Chromium and then even after you close it your original Chromium is janked up.

gitea-mirror commented

2026-05-05 06:59:12 -06:00

Author

Owner

@SYN-cook commented on GitHub (Apr 30, 2017):

I didn't try to reproduce your particular problem, but on my KDE system xdg-open generally gives precedence to ~/.local/share/applications, even when run from within Firejail.

Is this folder visible in your sandbox? Or does the problem disappear with the --noprofile option?

@SYN-cook commented on GitHub (Apr 30, 2017): I didn't try to reproduce your particular problem, but on my KDE system xdg-open generally gives precedence to `~/.local/share/applications`, even when run from within Firejail. Is this folder visible in your sandbox? Or does the problem disappear with the `--noprofile` option?

gitea-mirror commented

2026-05-05 06:59:14 -06:00

Author

Owner

@cryzed commented on GitHub (Apr 30, 2017):

@SpotComms you are right, doing it that way would be quite annoying. Maybe some kind of overlay FUSE filesystem mounted on top of bin-directories... I am aware that this sounds a bit silly though. I simply can't imagine another way to guarantee that all applications are started in a Sandbox elsewise. Thanks for the join-or-start suggestion, I'll take a look at that.

@SYN-cook you are right, I didn't consider this at all -- that was dumb of me. I would need to whitelist that directory of course; I had assumed, since in my theory an unsandboxed launcher is responsible for launching the desktop file in the end, that it would not matter if the directory is whitelisted or not. I'll try that.

@cryzed commented on GitHub (Apr 30, 2017): @SpotComms you are right, doing it that way would be quite annoying. Maybe some kind of overlay FUSE filesystem mounted on top of bin-directories... I am aware that this sounds a bit silly though. I simply can't imagine another way to guarantee that _all_ applications are started in a Sandbox elsewise. Thanks for the `join-or-start` suggestion, I'll take a look at that. @SYN-cook you are right, I didn't consider this at all -- that was dumb of me. I would need to whitelist that directory of course; I had assumed, since in my theory an unsandboxed launcher is responsible for launching the desktop file in the end, that it would not matter if the directory is whitelisted or not. I'll try that.

gitea-mirror commented

2026-05-05 06:59:15 -06:00

Author

Owner

@SkewedZeppelin commented on GitHub (Apr 30, 2017):

@cryzed Oh please no, overlayfs/FUSE over /usr/bin would be atrocious in so many ways. Using LD_PRELOAD might work or even a small kernel module that maintains a list of programs with their true paths and executes Firejail instead, but then you'd need DKMS and thats just annoying.

@SkewedZeppelin commented on GitHub (Apr 30, 2017): @cryzed Oh please no, overlayfs/FUSE over /usr/bin would be *atrocious in so many ways*. Using LD_PRELOAD might work or even a small kernel module that maintains a list of programs with their true paths and executes Firejail instead, but then you'd need DKMS and thats just annoying.

gitea-mirror commented

2026-05-05 06:59:18 -06:00

Author

Owner

@cryzed commented on GitHub (Apr 30, 2017):

@SpotComms alright. I didn't even know/consider that was an option to be honest, thanks for informing me.

@cryzed commented on GitHub (Apr 30, 2017): @SpotComms alright. I didn't even know/consider that was an option to be honest, thanks for informing me.

gitea-mirror commented

2026-05-05 06:59:20 -06:00

Author

Owner

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

in this case for some reason the system-wide *.desktop file located in /usr/share/applications instead of the one located in the user-local ~/.local/share/applications folder

This is a bug for KDE people.

it would be very nice if there was a way for firejail to check if the current launch of an application was started originally from an existing firejail environment and then ideally start the application using its own existing profile

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

@netblue30 commented on GitHub (May 1, 2017): > in this case for some reason the system-wide *.desktop file located in /usr/share/applications instead of the one located in the user-local ~/.local/share/applications folder This is a bug for KDE people. > it would be very nice if there was a way for firejail to check if the current launch of an application was started originally from an existing firejail environment and then ideally start the application using its own existing profile Unfortunately that's not possible, the first sandbox will not allow the second sandbox to rise privileges and set up the profile.

gitea-mirror commented

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

Author

Owner

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

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

I feared as much. I could imagine creating some kind of "bridge" to the outside for sandboxes. Instead of executing an application within the sandbox, one would execute bridge <path> [arguments], and the bridge would contact an instance of itself running unsandboxed and execute the command, however only if the path was specifically whitelisted for this instance beforehand. I have something rudimentary like that written in Python, but I'm not sure if you think adding this kind of functionality is a bad idea/overkill.

I'll close this for now I suppose, feel free to re-open this if you think that this might be a nice workaround at some point.

@cryzed commented on GitHub (May 2, 2017): > Unfortunately that's not possible, the first sandbox will not allow the second sandbox to rise privileges and set up the profile. I feared as much. I could imagine creating some kind of "bridge" to the outside for sandboxes. Instead of executing an application within the sandbox, one would execute `bridge <path> [arguments]`, and the bridge would contact an instance of itself running unsandboxed and execute the command, however only if the path was specifically whitelisted for this instance beforehand. I have something rudimentary like that written in Python, but I'm not sure if you think adding this kind of functionality is a bad idea/overkill. I'll close this for now I suppose, feel free to re-open this if you think that this might be a nice workaround at some point.

gitea-mirror commented

2026-05-05 06:59:26 -06:00

Author

Owner

@rahiel commented on GitHub (May 27, 2017):

@cryzed Some time ago I made a little tool called firectl, it prepends "firejail" to the Exec line of the system-wide desktop files. When the Debian/Ubuntu package is installed, it registers a dpkg-trigger, so when an update overwrites the desktop file, firectl is invoked and it adds "firejail" to them again.

This might be a solution if you run a Debian/Ubuntu based system. It's also viable for other distro's but the package with trigger/hook must then first be made.

EDIT: firectl is now deprecated!

@rahiel commented on GitHub (May 27, 2017): @cryzed Some time ago I made a little tool called [firectl](https://github.com/rahiel/firectl), it prepends "firejail" to the Exec line of the system-wide desktop files. When the Debian/Ubuntu package is installed, it registers a dpkg-trigger, so when an update overwrites the desktop file, firectl is invoked and it adds "firejail" to them again. This might be a solution if you run a Debian/Ubuntu based system. It's also viable for other distro's but the package with trigger/hook must then first be made. EDIT: firectl is now deprecated!

gitea-mirror referenced this issue

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

[PR #856] [MERGED] minor fixes #3772

Rows
Columns

[GH-ISSUE #1256] More reliable alternative to /usr/local/bin #856