github-starred/firejail

Fork 0

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

[GH-ISSUE #3601] Improving symlink invocation? #2257

New issue

Closed

opened 2026-05-05 08:57:01 -06:00 by gitea-mirror · 3 comments

gitea-mirror commented

2026-05-05 08:57:01 -06:00

Owner

Originally created by @curiosityseeker on GitHub (Aug 25, 2020).
Original GitHub issue: https://github.com/netblue30/firejail/issues/3601

Symlink invocation was introduced in Firejail 0.9.38, and since then it has been automated by executing sudo firecfg to make sure that all applications with a Firejail profile will start sandboxed.

While this works well in most cases we all know that there are, at least, two problems with this approach:

It doesn't work if /usr/local/bin isn't set before /usr/bin in the $PATH. This happens rarely - but I have seen such distros in the past. While this can be easily adjusted, the user has to aware of this problem and know how to do it.
It's easy to bypass Firejail by executing the respective application with its full path. Either intentionally - or quite often because an application is set as a helper application with its full path in another application.

So how can we improve that situation? One idea that came to my mind is the following: Change the behavior of firecfg such that it

renames the applications to be sandboxed, e.g., usr/bin/firefox to /usr/bin/firefox-fj,
creates symlinks in /usr/bin, e.g., /usr/bin/firefox, pointing to /usr/bin/firejail (needless to say that the symlinks in /usr/local/bin are consequently no longer needed)
makes sure that firejail executes /usr/bin/firefox-fj
and possibly applies chown root:firejail /usr/bin/*-fj and chmod 4750 /usr/bin/*-fj as explained here.

This would make sure that the respective applications will always be sandboxed regardless if they are executed with their full path or not.

An obvious problem is that the symlinks created in /usr/bin would be overwritten with every update of the respective applications. A possible solution is that we create hooks for the various package managers similarly like the one mentioned here.

What do you think? Does this make sense? Or is it a crazy or too complicate idea? Did I miss other problems?

Originally created by @curiosityseeker on GitHub (Aug 25, 2020). Original GitHub issue: https://github.com/netblue30/firejail/issues/3601 Symlink invocation was [introduced](https://l3net.wordpress.com/2016/02/04/firejail-0-9-38-release-announcement/) in Firejail 0.9.38, and since then it has been automated by executing `sudo firecfg` to make sure that all applications with a Firejail profile will start sandboxed. While this works well in most cases we all know that there are, at least, two problems with this approach: 1. It doesn't work if `/usr/local/bin` isn't set before `/usr/bin` in the $PATH. This happens rarely - but I have seen such distros in the past. While this can be easily adjusted, the user has to aware of this problem and know how to do it. 2. It's easy to bypass Firejail by executing the respective application with its full path. Either intentionally - or quite often because an application is set as a helper application with its full path in another application. So how can we improve that situation? One idea that came to my mind is the following: Change the behavior of firecfg such that it 1. renames the applications to be sandboxed, e.g., `usr/bin/firefox` to `/usr/bin/firefox-fj`, 2. creates symlinks in `/usr/bin`, e.g., `/usr/bin/firefox`, pointing to `/usr/bin/firejail` (needless to say that the symlinks in `/usr/local/bin` are consequently no longer needed) 3. makes sure that firejail executes `/usr/bin/firefox-fj` 4. and possibly applies `chown root:firejail /usr/bin/*-fj` and `chmod 4750 /usr/bin/*-fj` as explained [here](https://firejail.wordpress.com/documentation-2/basic-usage/#suid). This would make sure that the respective applications will always be sandboxed regardless if they are executed with their full path or not. An obvious problem is that the symlinks created in `/usr/bin` would be overwritten with every update of the respective applications. A possible solution is that we create hooks for the various package managers similarly like the one mentioned [here](https://wiki.archlinux.org/index.php/Firejail#Using_Firejail_by_default). What do you think? Does this make sense? Or is it a crazy or too complicate idea? Did I miss other problems?

gitea-mirror closed this issue

2026-05-05 08:57:02 -06:00

gitea-mirror commented

2026-05-05 08:57:04 -06:00

Author

Owner

@rusty-snake commented on GitHub (Aug 25, 2020):

Manipulating binaries in /usr/bin which are "owned" by a package-manager is IMHO a bad idea. It will likely make more trouble then good.

It may be possible to use /etc/fstab to bind-mount a helper script over /usr/bin/foo and bind-mount /usr/bin/foo under /bar/firejail/baz/foo. However, package-managers can then no longer make updates (except if we provide a undo-script/boot-entry).

Forcing programs in a sandbox belongs IMO in the kernel-space and isn't a task for the user-space. Use AppArmor or SELinux if you want to force a program in a sandbox.

Regarding point 1: We could warn the user. Sadly sudo changes $PATH.

@rusty-snake commented on GitHub (Aug 25, 2020): Manipulating binaries in /usr/bin which are "owned" by a package-manager is IMHO a bad idea. It will likely make more trouble then good. It may be possible to use /etc/fstab to bind-mount a helper script over /usr/bin/foo and bind-mount /usr/bin/foo under /bar/firejail/baz/foo. However, package-managers can then no longer make updates (except if we provide a undo-script/boot-entry). Forcing programs in a sandbox belongs IMO in the kernel-space and isn't a task for the user-space. Use AppArmor or SELinux if you want to force a program in a sandbox. Regarding point 1: We could warn the user. Sadly sudo changes $PATH.

gitea-mirror commented

2026-05-05 08:57:06 -06:00

Author

Owner

@FOSSONLY commented on GitHub (Aug 26, 2020):

Regarding point 1:
The problem with the PATH variable, from a realistic point of view, only affects exotic or largely insignificant linux distributions. And considering that the big and most important linux distributions are completely unproblematic in this respect, it is difficult to see a real problem here. Is it really necessary to support every workflow, no matter how exotic and not standard-compliant?

Regarding point 2:
From my point of view, firejail could be used as a restricted shell. This way, the login shell would always be isolated, but could in principle start nothing else but isolated programs (even with absolute paths). And the default profile could be further customized via the configuration.

@FOSSONLY commented on GitHub (Aug 26, 2020): Regarding point 1: The problem with the PATH variable, from a realistic point of view, only affects exotic or largely insignificant linux distributions. And considering that the big and most important linux distributions are completely unproblematic in this respect, it is difficult to see a real problem here. Is it really necessary to support every workflow, no matter how exotic and not standard-compliant? Regarding point 2: From my point of view, firejail could be used as a restricted shell. This way, the login shell would always be isolated, but could in principle start nothing else but isolated programs (even with absolute paths). And the default profile could be further customized via the configuration.

gitea-mirror commented

2026-05-05 08:57:07 -06:00

Author

Owner

@curiosityseeker commented on GitHub (Aug 26, 2020):

Okay, it was a bad idea. Closing.

@curiosityseeker commented on GitHub (Aug 26, 2020): Okay, it was a bad idea. Closing.

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

No description provided.

Rows
Columns