[GH-ISSUE #2505] new *-common includes

gitea-mirror commented

2026-05-05 08:16:58 -06:00

Owner

Originally created by @smitsohu on GitHub (Mar 2, 2019).
Original GitHub issue: https://github.com/netblue30/firejail/issues/2505

How about two more includes, one collecting various noexec directives in one place, and the other collecting some common whitelisting in /run/user/$UID?

A noexec-common.inc (or whatever the name) could for example look like

noexec ${HOME}
noexec ${RUNUSER}
noexec /dev/shm
noexec /tmp
noexec /var

(adapted from a suggestion of @Vincent43) and go to all profiles that have an apparmor option currently. As this duplicates apparmor restrictions, there is obviously only limited value for people who run firejail with apparmor enabled. But for everyone else it could be an important addition.

A simple whitelist-run-common.inc (or whatever the name)

whitelist ${RUNUSER}/bus
whitelist ${RUNUSER}/pulse

should be sufficient for most of the programs. Some profiles (those with writable-run-user option) will need an extra line whitelist ${RUNUSER}/gnupg.

Btw, what usually doesn't work is whitelist ${RUNUSER}/gvfs, because of the broken Firejail - FUSE interaction.

Originally created by @smitsohu on GitHub (Mar 2, 2019). Original GitHub issue: https://github.com/netblue30/firejail/issues/2505 How about two more includes, one collecting various noexec directives in one place, and the other collecting some common whitelisting in /run/user/$UID? A noexec-common.inc (or whatever the name) could for example look like ``` noexec ${HOME} noexec ${RUNUSER} noexec /dev/shm noexec /tmp noexec /var ``` (adapted from a suggestion of @Vincent43) and go to all profiles that have an `apparmor` option currently. As this duplicates apparmor restrictions, there is obviously only limited value for people who run firejail with apparmor enabled. But for everyone else it could be an important addition. A simple whitelist-run-common.inc (or whatever the name) ``` whitelist ${RUNUSER}/bus whitelist ${RUNUSER}/pulse ``` should be sufficient for most of the programs. Some profiles (those with `writable-run-user` option) will need an extra line `whitelist ${RUNUSER}/gnupg`. Btw, what usually doesn't work is `whitelist ${RUNUSER}/gvfs`, because of the broken Firejail - FUSE interaction.

gitea-mirror

2026-05-05 08:16:58 -06:00

closed this issue
added the
enhancement
label

gitea-mirror commented

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

Author

Owner

@Vincent43 commented on GitHub (Mar 3, 2019):

I wonder if we could sneak-in those in disable-common.inc and whitelist-common.inc.

@Vincent43 commented on GitHub (Mar 3, 2019): I wonder if we could sneak-in those in `disable-common.inc` and `whitelist-common.inc`.

gitea-mirror commented

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

Author

Owner

@smitsohu commented on GitHub (Mar 6, 2019):

I wonder if we could sneak-in those in disable-common.inc and whitelist-common.inc.

Good question. noexec ${HOME} and noexec /dev/shm can be problematic, I was a bit worried about breaking many profiles.

Regarding the whitelisting in /run/user, I currently cannot really overlook the consequences of removing the gvfs mount point. From what I'm reading, Gnome media players or image managers might run into issues.

@smitsohu commented on GitHub (Mar 6, 2019): > I wonder if we could sneak-in those in disable-common.inc and whitelist-common.inc. Good question. `noexec ${HOME}` and `noexec /dev/shm` can be problematic, I was a bit worried about breaking many profiles. Regarding the whitelisting in /run/user, I currently cannot really overlook the consequences of removing the gvfs mount point. From what I'm reading, Gnome media players or image managers might run into issues.

gitea-mirror commented

2026-05-05 08:17:03 -06:00

Author

Owner

@Vincent43 commented on GitHub (Mar 6, 2019):

Ok. Let's introduce noexec-common.inc then and use it to replace noexec rules in app profiles gradually.

@Vincent43 commented on GitHub (Mar 6, 2019): Ok. Let's introduce `noexec-common.inc` then and use it to replace `noexec` rules in app profiles gradually.

gitea-mirror commented

2026-05-05 08:17:05 -06:00

Author

Owner

@smitsohu commented on GitHub (Mar 11, 2019):

Or maybe disable-exec.inc? We can call it from anywhere in the profile, so it could go to the disable-* block as well.

@smitsohu commented on GitHub (Mar 11, 2019): Or maybe `disable-exec.inc`? We can call it from anywhere in the profile, so it could go to the disable-* block as well.

gitea-mirror commented

2026-05-05 08:17:06 -06:00

Author

Owner

@Vincent43 commented on GitHub (Mar 11, 2019):

Yes, it may fit better.

@Vincent43 commented on GitHub (Mar 11, 2019): Yes, it may fit better.

gitea-mirror commented

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

Author

Owner

@Boruch-Baum commented on GitHub (Mar 19, 2019):

Is it possible to have a sort-of whitelist command as an exception to noexec? For example, here I have a solution for applying cpulimits to firejails, but it only works in that case because the default profile for firefox has the noexec line commented out; when the noexec line is active, the script in ~/.local/bin can't be executed, even though it initiated the call to firejail!

I'm sure there will be other examples of a limited number of executables of interest in $HOME for a particular program, and that shouldn't be a deal-breaker for losing the noexec feature for the rest of $HOME. Maybe one example would be mutt, which calls in a strange mix of plug-ins and scripts, including indirectly calling scripts in one's $HOME. Also, the less browser has options for lesspipe and highlighting that call in scripts local to $HOME, so any program that calls the less browser will lose that functionality if noexec $HOME is enabled.

@Boruch-Baum commented on GitHub (Mar 19, 2019): Is it possible to have a sort-of `whitelist` command as an exception to `noexec`? For example, [here](https://github.com/netblue30/firejail/issues/2324#issuecomment-474517220) I have a solution for applying cpulimits to firejails, but it only works in that case because the default profile for firefox has the noexec line commented out; when the noexec line is active, the script in `~/.local/bin` can't be executed, even though it initiated the call to firejail! I'm sure there will be other examples of a limited number of executables of interest in `$HOME` for a particular program, and that shouldn't be a deal-breaker for losing the `noexec` feature for the rest of `$HOME`. Maybe one example would be `mutt`, which calls in a strange mix of plug-ins and scripts, including indirectly calling scripts in one's `$HOME`. Also, the `less` browser has options for `lesspipe` and highlighting that call in scripts local to `$HOME`, so any program that calls the `less` browser will lose that functionality if `noexec $HOME` is enabled.

gitea-mirror commented

2026-05-05 08:17:08 -06:00

Author

Owner

@Boruch-Baum commented on GitHub (Mar 19, 2019):

Another reason to support the idea of some sort of over-ride to noexec is so that a local unprivileged user can put it in their personal ~/.config/firejail profile without having to edit anything in /etc/firejail. Also, let's say someone does perform the edit, ie. comments out a noexec line in /etc/firejail, won't the edit be over-written on the next package update? There would need to be some command suitable for /etc/firejail/foo.local in that case, which would have to be an over-ride.

@Boruch-Baum commented on GitHub (Mar 19, 2019): Another reason to support the idea of some sort of over-ride to `noexec` is so that a local unprivileged user can put it in their personal `~/.config/firejail` profile without having to edit anything in `/etc/firejail`. Also, let's say someone does perform the edit, ie. comments out a `noexec` line in `/etc/firejail`, won't the edit be over-written on the next package update? There would need to be some command suitable for `/etc/firejail/foo.local` in that case, which would have to be an over-ride.

gitea-mirror commented

2026-05-05 08:17:09 -06:00

Author

Owner

@Boruch-Baum commented on GitHub (Mar 19, 2019):

Maybe a way to implement my feature-request would be a tweak to private-bin which seems to create and mount a virtual /bin to allow full path-names to over-ride the virtual remount performed by noexec? I'm not familiar with the firejail internals so that's just an idea.

@Boruch-Baum commented on GitHub (Mar 19, 2019): Maybe a way to implement my feature-request would be a tweak to `private-bin` which seems to create and mount a virtual `/bin` to allow full path-names to over-ride the virtual remount performed by `noexec`? I'm not familiar with the firejail internals so that's just an idea.

gitea-mirror commented

2026-05-05 08:17:09 -06:00

Author

Owner

@ghost commented on GitHub (Mar 19, 2019):

Is it possible to have a sort-of whitelist command as an exception to noexec?

Maybe you're looking for the ignore option, which is also still supported in the implementation of disable-exec.inc. For example, let's suppose /etc/firejail/foo.profile has the noexec ${HOME} option (either in the 'old' form or via the newly introduced 'include disable-exec.inc' syntax). If a user puts something like ignore noexec ${HOME} in ~/.config/firejail/foo.local, that will always have precedence and already does what (I think) you describe. But if you mean a more granular exception (use noexec ${HOME} but ignore it for ~/.local/bin/foo only), I don't think that's possible (yet).

Also, let's say someone does perform the edit, ie. comments out a noexec line in /etc/firejail, won't the edit be over-written on the next package update?

Exactly, which is why all of the .profile files in /etc/firejail have comments inside to inform the (reading) user:

...
# This file is overwritten after every install/update
# Persistent local customizations
include foo.local
# Persistent global definitions
include globals.local
...

Is this what you're refering to by feature-request?

@ghost commented on GitHub (Mar 19, 2019): > Is it possible to have a sort-of whitelist command as an exception to noexec? Maybe you're looking for the `ignore` option, which is also still supported in the implementation of disable-exec.inc. For example, let's suppose /etc/firejail/foo.profile has the `noexec ${HOME}` option (either in the 'old' form or via the newly introduced 'include disable-exec.inc' syntax). If a user puts something like `ignore noexec ${HOME}` in ~/.config/firejail/foo.local, that will always have precedence and already does what (I think) you describe. But if you mean a more granular exception (use noexec ${HOME} but ignore it for ~/.local/bin/foo only), I don't think that's possible (yet). > Also, let's say someone does perform the edit, ie. comments out a noexec line in /etc/firejail, won't the edit be over-written on the next package update? Exactly, which is why all of the .profile files in /etc/firejail have comments inside to inform the (reading) user: ``` ... # This file is overwritten after every install/update # Persistent local customizations include foo.local # Persistent global definitions include globals.local ... ``` Is this what you're refering to by feature-request?

gitea-mirror commented

2026-05-05 08:17:10 -06:00

Author

Owner

@Boruch-Baum commented on GitHub (Mar 19, 2019):

But if you mean a more granular exception (use noexec ${HOME} but ignore it for ~/.local/bin/foo only), I don't think that's possible (yet).
...
Is this what you're refering to by feature-request?

@glitsj16 : Yes, a more granular could allow users to do things like have personal wrapper scripts to launch firejail (see above my example for launching firefox with cpulimit), and have executables tie into personal plug-ins, (see above my example re: lessfilter, lesspipe, and it just occurred to me that midnight commander would also benefit).

Thanks for the advice about the ignore command, which I had missed.

@Boruch-Baum commented on GitHub (Mar 19, 2019): >But if you mean a more granular exception (use noexec ${HOME} but ignore it for ~/.local/bin/foo only), I don't think that's possible (yet). >... > Is this what you're refering to by feature-request? @glitsj16 : Yes, a more granular could allow users to do things like have personal wrapper scripts to launch firejail (see above my example for launching firefox with cpulimit), and have executables tie into personal plug-ins, (see above my example re: lessfilter, lesspipe, and it just occurred to me that midnight commander would also benefit). Thanks for the advice about the `ignore` command, which I had missed.

gitea-mirror commented

2026-05-05 08:17:11 -06:00

Author

Owner

@rusty-snake commented on GitHub (May 1, 2019):

I would suggest whitelist-usr-share-common.inc

@rusty-snake commented on GitHub (May 1, 2019): I would suggest `whitelist-usr-share-common.inc`

gitea-mirror commented

2026-05-05 08:17:12 -06:00

Author

Owner

@rusty-snake commented on GitHub (Jan 18, 2020):

disable-obsolete.inc for obsolete (EOL/EOS) software.(#3164)

@rusty-snake commented on GitHub (Jan 18, 2020): `disable-obsolete.inc` for obsolete (EOL/EOS) software.(#3164)

gitea-mirror commented

2026-05-05 08:17:12 -06:00

Author

Owner

@rusty-snake commented on GitHub (Apr 1, 2020):

Should we close here?

@rusty-snake commented on GitHub (Apr 1, 2020): Should we close here?

gitea-mirror commented

2026-05-05 08:17:13 -06:00

Author

Owner

@smitsohu commented on GitHub (Apr 2, 2020):

Let's close.

@smitsohu commented on GitHub (Apr 2, 2020): Let's close.

Rows
Columns

[GH-ISSUE #2505] new *-common includes #1631