[GH-ISSUE #397] Make all programs start with firejail automatically

gitea-mirror commented

2026-05-05 05:31:40 -06:00

Owner

Originally created by @ghost on GitHub (Mar 31, 2016).
Original GitHub issue: https://github.com/netblue30/firejail/issues/397

Is there a way to tell firejail to start all userspace programs with it automatically? If not can it be added?

Originally created by @ghost on GitHub (Mar 31, 2016). Original GitHub issue: https://github.com/netblue30/firejail/issues/397 Is there a way to tell firejail to start all userspace programs with it automatically? If not can it be added?

gitea-mirror

2026-05-05 05:31:40 -06:00

closed this issue
added the
information_old
label

gitea-mirror commented

2026-05-05 05:31:45 -06:00

Author

Owner

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

It is kind of difficult, it would require same sort of kernel support. So far we can only start firejail automatically if the application is started from a .desktop file. Such is the case with desktop manager menus and icons, or from command line. The relevant information is this:

DESKTOP INTEGRATION
       A  symbolic link to /usr/bin/firejail under the name of a program, will
       start the program in Firejail sandbox.  The  symbolic  link  should  be
       placed  in  the  first $PATH position. On most systems, a good place is
       /usr/local/bin directory. Example:

              Make a firefox symlink to /usr/bin/firejail:

              $ ln -s /usr/bin/firejail /usr/local/bin/firefox

              Verify $PATH

              $ which -a firefox
              /usr/local/bin/firefox
              /usr/bin/firefox

              Starting firefox in this moment, automatically invokes “firejail
              firefox”.

       This  works  for  clicking on desktop environment icons, menus etc. Use
       "firejail --tree" to verify the program is sandboxed.

              $ firejail --tree
              1189:netblue:firejail firefox
                1190:netblue:firejail firefox
                  1220:netblue:/bin/sh -c "/usr/lib/firefox/firefox"
                    1221:netblue:/usr/lib/firefox/firefox

@netblue30 commented on GitHub (Apr 1, 2016): It is kind of difficult, it would require same sort of kernel support. So far we can only start firejail automatically if the application is started from a .desktop file. Such is the case with desktop manager menus and icons, or from command line. The relevant information is this: ``` DESKTOP INTEGRATION A symbolic link to /usr/bin/firejail under the name of a program, will start the program in Firejail sandbox. The symbolic link should be placed in the first $PATH position. On most systems, a good place is /usr/local/bin directory. Example: Make a firefox symlink to /usr/bin/firejail: $ ln -s /usr/bin/firejail /usr/local/bin/firefox Verify $PATH $ which -a firefox /usr/local/bin/firefox /usr/bin/firefox Starting firefox in this moment, automatically invokes “firejail firefox”. This works for clicking on desktop environment icons, menus etc. Use "firejail --tree" to verify the program is sandboxed. $ firejail --tree 1189:netblue:firejail firefox 1190:netblue:firejail firefox 1220:netblue:/bin/sh -c "/usr/lib/firefox/firefox" 1221:netblue:/usr/lib/firefox/firefox ```

gitea-mirror commented

2026-05-05 05:31:47 -06:00

Author

Owner

@HulaHoopWhonix commented on GitHub (Apr 8, 2016):

What if something like incron is used to monitor the filesystem and execute the firejail command upon detecting the start-up of a program file which has a confinement profile? The original access would be terminated by closing the file and instead the firejail command is executed in its place.

(inotify cron daemon) is a daemon which monitors filesystem events (such as add a new file, delete a file and so on) and executes commands or shell scripts. It’s use is generally similar to cron.

http://www.cyberciti.biz/faq/linux-inotify-examples-to-replicate-directories/

Available in Debian:

https://packages.debian.org/stretch/incron

EDIT:

Additionally there could be a global setting that forces any other programs without profiles to run under the generic one which is a step up in protection even if its not as secure as a tailored profile.

END OF EDIT

If the above idea doesn't work, the way Oz is doing this is:

Enabling a profile

Once installed you can enable profiles using the oz-setup command as such (using the profile for the 'evince' application):

$ sudo oz-setup install evince

This will install a symlink to the oz client executable in place of the original, the original executable will be moved to dirname(path)-oz/basename(path).unsafe. This behavior can be altered using the divert_path and divert_suffix configuration flags.
Disabling a profile

If you want to disable a profile that you're not using or prior to uninstalling Oz, you can run the following command (once again with 'evince' as the target application):

$ sudo oz-setup remove evince

If you have already uninstalled Oz you can remove the divertions manually using the dpkg-divert command.

https://github.com/subgraph/oz

@HulaHoopWhonix commented on GitHub (Apr 8, 2016): What if something like incron is used to monitor the filesystem and execute the firejail command upon detecting the start-up of a program file which has a confinement profile? The original access would be terminated by closing the file and instead the firejail command is executed in its place. > (inotify cron daemon) is a daemon which monitors filesystem events (such as add a new file, delete a file and so on) and executes commands or shell scripts. It’s use is generally similar to cron. http://www.cyberciti.biz/faq/linux-inotify-examples-to-replicate-directories/ Available in Debian: https://packages.debian.org/stretch/incron EDIT: Additionally there could be a global setting that forces any other programs without profiles to run under the generic one which is a step up in protection even if its not as secure as a tailored profile. END OF EDIT --- If the above idea doesn't work, the way Oz is doing this is: > Enabling a profile > > Once installed you can enable profiles using the oz-setup command as such (using the profile for the 'evince' application): > > $ sudo oz-setup install evince > > This will install a symlink to the oz client executable in place of the original, the original executable will be moved to dirname(path)-oz/basename(path).unsafe. This behavior can be altered using the divert_path and divert_suffix configuration flags. > Disabling a profile > > If you want to disable a profile that you're not using or prior to uninstalling Oz, you can run the following command (once again with 'evince' as the target application): > > $ sudo oz-setup remove evince > > If you have already uninstalled Oz you can remove the divertions manually using the dpkg-divert command. https://github.com/subgraph/oz

gitea-mirror commented

2026-05-05 05:31:49 -06:00

Author

Owner

@netblue30 commented on GitHub (Apr 9, 2016):

inotify: the problem is by the time you get the notification, the kernel already started the program. The events you receive from the kernel are asynchronous.

For Oz people is easy, they are a distribution and they can control what gets installed on the user system. On a regular disro, once you update a program like Firefox, the update will replace the link with whatever is in the new package.

@netblue30 commented on GitHub (Apr 9, 2016): inotify: the problem is by the time you get the notification, the kernel already started the program. The events you receive from the kernel are asynchronous. For Oz people is easy, they are a distribution and they can control what gets installed on the user system. On a regular disro, once you update a program like Firefox, the update will replace the link with whatever is in the new package.

gitea-mirror commented

2026-05-05 05:31:51 -06:00

Author

Owner

@HulaHoopWhonix commented on GitHub (Apr 10, 2016):

Orthogonal to the first idea is to use some form of hooking https://en.wikipedia.org/wiki/Hooking#Linux to control the execution of other processes. ptrace might not work on Grsec kernels however.

For Oz people is easy, they are a distribution and they can control what gets installed on the user system. On a regular disro, once you update a program like Firefox, the update will replace the link with whatever is in the new package.

You can use Dpkg hooks (DPkg::Post-Invoke) to ensure symlinks are maintained even across software updates.

@HulaHoopWhonix commented on GitHub (Apr 10, 2016): Orthogonal to the first idea is to use some form of hooking https://en.wikipedia.org/wiki/Hooking#Linux to control the execution of other processes. ptrace might not work on Grsec kernels however. > For Oz people is easy, they are a distribution and they can control what gets installed on the user system. On a regular disro, once you update a program like Firefox, the update will replace the link with whatever is in the new package. You can use Dpkg hooks (DPkg::Post-Invoke) to ensure symlinks are maintained even across software updates.

gitea-mirror commented

2026-05-05 05:31:53 -06:00

Author

Owner

@netblue30 commented on GitHub (Apr 10, 2016):

Ptrace syscall is disabled by seccomp.

Dpkg hooks will give firejail too much control over the user desktop, I think we should stay away. The user still can implement it, but for us to change how the package manager works would be very intrusive.

@netblue30 commented on GitHub (Apr 10, 2016): Ptrace syscall is disabled by seccomp. Dpkg hooks will give firejail too much control over the user desktop, I think we should stay away. The user still can implement it, but for us to change how the package manager works would be very intrusive.

gitea-mirror commented

2026-05-05 05:31:56 -06:00

Author

Owner

@FedericoCeratto commented on GitHub (Apr 10, 2016):

dpkg-divert and update-alternatives, used together, can do the trick - but for one application at a time:

# Create a wrapper
cat > /opt/firejail_shim <<EOF
#!/bin/sh
/usr/bin/firejail $0.firejailed
EOF
chmod +x /opt/firejail_shim

# Divert the real binary
dpkg-divert --divert /usr/bin/nmap.firejailed --rename /usr/bin/nmap
update-alternatives --install /usr/bin/nmap nmap /opt/firejail_shim 40

# Now /usr/bin/nmap is a symlink that will run the wrapper that will run firejail
file /usr/bin/nmap

# Reinstalling nmap will not break this little kludge
apt-get install --reinstall nmap

# Cleanup
update-alternatives --remove nmap /opt/firejail_shim; dpkg-divert --remove /usr/bin/nmap; rm /opt/firejail_shim

@FedericoCeratto commented on GitHub (Apr 10, 2016): dpkg-divert and update-alternatives, used together, can do the trick - but for one application at a time: ``` bash # Create a wrapper cat > /opt/firejail_shim <<EOF #!/bin/sh /usr/bin/firejail $0.firejailed EOF chmod +x /opt/firejail_shim # Divert the real binary dpkg-divert --divert /usr/bin/nmap.firejailed --rename /usr/bin/nmap update-alternatives --install /usr/bin/nmap nmap /opt/firejail_shim 40 # Now /usr/bin/nmap is a symlink that will run the wrapper that will run firejail file /usr/bin/nmap # Reinstalling nmap will not break this little kludge apt-get install --reinstall nmap # Cleanup update-alternatives --remove nmap /opt/firejail_shim; dpkg-divert --remove /usr/bin/nmap; rm /opt/firejail_shim ```

gitea-mirror commented

2026-05-05 05:31:58 -06:00

Author

Owner

@HulaHoopWhonix commented on GitHub (Apr 10, 2016):

Dpkg hooks will give firejail too much control over the user desktop, I think we should say away. The user still can implement it, but for us to change how the package manager works would be very intrusive.

Not really. GRsec's paxctl uses a similar technique for re-applying PaX flags to updated binaries. You can make this behavior optional on Firejail's first start by asking the user if they want to enable it.

Automatically starting programs under protection is the single biggest usability feature IMO. A regular user should not have to use the command line or even know what a symlink is to benefit from Firejail. Making this opt-in sets the right balance.

Lets say a user wants to easily reverse this for some specific program. Firetools should immediately delete the symlink for any application whose icon is dragged outside its widget.

@HulaHoopWhonix commented on GitHub (Apr 10, 2016): > Dpkg hooks will give firejail too much control over the user desktop, I think we should say away. The user still can implement it, but for us to change how the package manager works would be very intrusive. Not really. GRsec's paxctl uses a similar technique for re-applying PaX flags to updated binaries. You can make this behavior optional on Firejail's first start by asking the user if they want to enable it. Automatically starting programs under protection is the single biggest usability feature IMO. A regular user should not have to use the command line or even know what a symlink is to benefit from Firejail. Making this opt-in sets the right balance. --- Lets say a user wants to easily reverse this for some specific program. Firetools should immediately delete the symlink for any application whose icon is dragged outside its widget.

gitea-mirror commented

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

Author

Owner

@requiredregistration commented on GitHub (Apr 11, 2016):

an ignorant and careless user will never be safe for long.

ease of use is something good, but making it easier to use must never lower security.

@requiredregistration commented on GitHub (Apr 11, 2016): an ignorant and careless user will never be safe for long. ease of use is something good, but making it easier to use must never lower security.

gitea-mirror commented

2026-05-05 05:32:01 -06:00

Author

Owner

@adrelanos commented on GitHub (Apr 19, 2016):

So far we can only start firejail automatically if the application is started from a .desktop file.

Which is problematic, since lots of users occasionally also start applications from the command line.

Dpkg hooks will give firejail too much control over the user desktop, I think we should stay away. The user still can implement it, but for us to change how the package manager works would be very intrusive.

So perhaps implemented in a separate optional package?

it would require same sort of kernel support.

Are the kernel developers already aware of the need for this feature? Is there a feature request already? Is this something you could implement into the kernel?

@adrelanos commented on GitHub (Apr 19, 2016): > So far we can only start firejail automatically if the application is started from a .desktop file. Which is problematic, since lots of users occasionally also start applications from the command line. > Dpkg hooks will give firejail too much control over the user desktop, I think we should stay away. The user still can implement it, but for us to change how the package manager works would be very intrusive. So perhaps implemented in a separate optional package? > it would require same sort of kernel support. Are the kernel developers already aware of the need for this feature? Is there a feature request already? Is this something you could implement into the kernel?

gitea-mirror commented

2026-05-05 05:32:02 -06:00

Author

Owner

@ghost commented on GitHub (Apr 19, 2016):

@netblue30 Please reopen the issue

@ghost commented on GitHub (Apr 19, 2016): @netblue30 Please reopen the issue

gitea-mirror commented

2026-05-05 05:32:03 -06:00

Author

Owner

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

Reopened!

@netblue30 commented on GitHub (Apr 20, 2016): Reopened!

gitea-mirror commented

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

Author

Owner

@HulaHoopWhonix commented on GitHub (May 10, 2016):

@netblue30 why didn't you mention firecfg? It does what I was looking for and the symlinks survive package upgrades :)

One thing I ran into was firecfg didn't create symlinks for Iceweasel although its installed and has a supported profile.

The link is created for firefox (which is rebranded on Debian to Iceweasel) but all the links on the system point to the name of the latter.

$ sudo firecfg --list
/usr/local/bin/icedove
/usr/local/bin/vlc
/usr/local/bin/xchat
/usr/local/bin/firefox

@HulaHoopWhonix commented on GitHub (May 10, 2016): @netblue30 why didn't you mention firecfg? It does what I was looking for and the symlinks survive package upgrades :) One thing I ran into was firecfg didn't create symlinks for Iceweasel although its installed and has a supported profile. The link is created for firefox (which is rebranded on Debian to Iceweasel) but all the links on the system point to the name of the latter. $ sudo firecfg --list /usr/local/bin/icedove /usr/local/bin/vlc /usr/local/bin/xchat /usr/local/bin/firefox

gitea-mirror commented

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

Author

Owner

@HulaHoopWhonix commented on GitHub (May 10, 2016):

Turns out the problem is caused because the Iceweasel profile redirects to the Firefox one for confinement rules. To fix this a full custom rule-set is needed for Iceweasel because its directory names are different.

@HulaHoopWhonix commented on GitHub (May 10, 2016): Turns out the problem is caused because the Iceweasel profile redirects to the Firefox one for confinement rules. To fix this a full custom rule-set is needed for Iceweasel because its directory names are different.

gitea-mirror commented

2026-05-05 05:32:07 -06:00

Author

Owner

@netblue30 commented on GitHub (May 11, 2016):

The version in github repository decouples firefox and iceweasel profiles. Each one has its own file in /etc/firejail directory. I have a new release coming in about one week - hopefully!

This is what you can do if you are on 0.9.38:

Create a ~/.config/firejail directory

$ mkdir ~/.config/firejail

Copy firefox.profile there as iceweasel.profile

$ cp /etc/firejail/firefox.profile ~/.config/firejail/iceweasel.profile

Open ~/.config/firejail/iceweasel.profile in a text editor and modify it.

@netblue30 commented on GitHub (May 11, 2016): The version in github repository decouples firefox and iceweasel profiles. Each one has its own file in /etc/firejail directory. I have a new release coming in about one week - hopefully! This is what you can do if you are on 0.9.38: Create a ~/.config/firejail directory ``` $ mkdir ~/.config/firejail ``` Copy firefox.profile there as iceweasel.profile ``` $ cp /etc/firejail/firefox.profile ~/.config/firejail/iceweasel.profile ``` Open ~/.config/firejail/iceweasel.profile in a text editor and modify it.

gitea-mirror commented

2026-05-05 05:32:08 -06:00

Author

Owner

@HulaHoopWhonix commented on GitHub (May 11, 2016):

Thank you. Sounds good. Feel free to close this ticket as the original topic has been covered.

EDIT:

I noticed a typo in the manpage where --clear is mentioned though it has been deprecated in favor of --clean.

https://firejail.wordpress.com/features-3/man-firecfg/

@HulaHoopWhonix commented on GitHub (May 11, 2016): Thank you. Sounds good. Feel free to close this ticket as the original topic has been covered. EDIT: I noticed a typo in the manpage where --clear is mentioned though it has been deprecated in favor of --clean. https://firejail.wordpress.com/features-3/man-firecfg/

gitea-mirror commented

2026-05-05 05:32:09 -06:00

Author

Owner

@netblue30 commented on GitHub (May 12, 2016):

clear/clean is fixed in git.

@netblue30 commented on GitHub (May 12, 2016): clear/clean is fixed in git.

gitea-mirror commented

2026-05-05 05:32:10 -06:00

Author

Owner

@hfont commented on GitHub (Feb 24, 2019):

Would it be possible to do this in the shell?

I was looking at this code here:

https://unix.stackexchange.com/questions/250713/modify-all-bash-commands-through-a-program-before-executing-them

@hfont commented on GitHub (Feb 24, 2019): Would it be possible to do this in the shell? I was looking at this code here: [https://unix.stackexchange.com/questions/250713/modify-all-bash-commands-through-a-program-before-executing-them](https://unix.stackexchange.com/questions/250713/modify-all-bash-commands-through-a-program-before-executing-them)

Rows
Columns

[GH-ISSUE #397] Make all programs start with firejail automatically #288