Cannot unblacklist /usr/libexec in firefox-common.local

[vinc17fr]

Description

In order to view some kinds of text files from Firefox (and potentially other similar web browsers), I need to run some text viewer, and GNU Emacs is the best one for me. However, with the new GNU Emacs 28 version under Debian, being able to access /usr/libexec/emacs is required, and this is currently not possible by default:

$ emacs
emacs: could not load dump file "/usr/libexec/emacs/28.1/x86_64-linux-gnu/emacs.pdmp": Permission denied

Though I could add noblacklist /usr/libexec to ~/.config/firejail/firefox.local to solve this issue, I would prefer to put everything to ~/.config/firejail/firefox-common.local, which is used by more profiles associated with web browsers. But adding noblacklist /usr/libexec there doesn't work as it is run too late (because firefox.profile includes firefox-common.profile at the end), and ignore blacklist /usr/libexec doesn't work either (for the same reason?). Moreover, whitelist /usr/libexec gives an error and whitelist /usr/libexec/emacs doesn't have any effect (due to the blacklist?).

If there is no way to unblacklist some blacklisted directory, the profiles need to be reworked to run firefox-common.local earlier; otherwise, what's the point of this so-called local customization?

Steps to Reproduce

1. Put noblacklist /usr/libexec and ignore blacklist /usr/libexec in ~/.config/firejail/firefox-common.local (do not use other local customization). Or do not use any local customization.
2. Run firejail --profile=firefox sh
3. Run emacs (if GNU Emacs 28 is installed) and/or ls -ld /usr/libexec.

Expected behavior

/usr/libexec should be accessible.

Actual behavior

/usr/libexec is not accessible; ls -ld /usr/libexec outputs permissions dr-------- instead of drwxr-xr-x.

Behavior without a profile

N/A: The issue is about profile configuration.

Environment

• Linux distribution and version: Debian/unstable
• Firejail version (firejail --version): 0.9.70 (Debian package firejail 0.9.70-1)

Checklist

• The issues is caused by firejail (i.e. running the program by path (e.g. /usr/bin/vlc) "fixes" it).
• I can reproduce the issue without custom modifications (e.g. globals.local).
• The program has a profile. (If not, request one in https://github.com/netblue30/firejail/issues/1139)
• The profile (and redirect profile if exists) hasn't already been fixed upstream.
• I have performed a short search for similar issues (to avoid opening a duplicate).
  • I'm aware of browser-allow-drm yes/browser-disable-u2f no in firejail.config to allow DRM/U2F in browsers.
• I used --profile=PROFILENAME to set the right profile. (Only relevant for AppImages)

[glitsj16]

If there is no way to unblacklist some blacklisted directory, the profiles need to be reworked to run firefox-common.local earlier; otherwise, what's the point of this so-called local customization?

We accept PR's. Although I can sympathize with your configuration issue, throwing out the baby with the bathwater seems a bit overkill IMO. Please consider this is not a bug, the recommended way works, as you state yourself. Currently we have exactly 13 other web browser profiles that include firefox-common.profile. Whether or not you're using all or some of them, if it's necessary to support your use case, the exact same workaround can be applied. Not willing to do the work is fine, but that's up to you. Besides, emacs has it's own dedicated profile and running it in the firefox sandbox is also your decision.

The latest emacs on Arch Linux installs files to /usr/share/emacs (nothing to /usr/libexec because that's discouraged on that OS). If on Debian this dir exists as well, you need to add whitelist /usr/share/emacs to your firefox.local.

In the mean time I've counted exactly 13 other web browser profiles that include firefox-common.profile. None of them have blacklist /usr/libexec. So if you'd like to open a PR, you could move it to firejail-common and see what other collaborators think of it. This is how open-source stuff works.

[kmk3]

@vinc17fr commented on Aug 24:

Description

In order to view some kinds of text files from Firefox (and potentially other
similar web browsers), I need to run some text viewer, and GNU Emacs is the
best one for me. However, with the new GNU Emacs 28 version under Debian,
being able to access /usr/libexec/emacs is required, and this is currently
not possible by default:

$ emacs
emacs: could not load dump file "/usr/libexec/emacs/28.1/x86_64-linux-gnu/emacs.pdmp": Permission denied

Though I could add noblacklist /usr/libexec to
~/.config/firejail/firefox.local to solve this issue, I would prefer to put
everything to ~/.config/firejail/firefox-common.local, which is used by
more profiles associated with web browsers. But adding noblacklist /usr/libexec there doesn't work as it is run too late (because
firefox.profile includes firefox-common.profile at the end), and ignore blacklist /usr/libexec doesn't work either (for the same reason?). Moreover,
whitelist /usr/libexec gives an error and whitelist /usr/libexec/emacs
doesn't have any effect (due to the blacklist?).

If there is no way to unblacklist some blacklisted directory, the profiles
need to be reworked to run firefox-common.local earlier; otherwise, what's
the point of this so-called local customization?

Suggestion:

Create a new profile, such as "webbrowser-common.profile" and include it in the
.local profile of every web browser that you use (note that the .local profile
is usually included before any blacklisting happens).

Then add the commands needed to allow emacs in it (or in a new
allow-emacs.profile file and include that instead).

[vinc17fr]

Replying to the last two comments:

Besides, emacs has it's own dedicated profile and running it in the firefox sandbox is also your decision.

It is not my decision. It is Firefox that runs Emacs (as an helper application) for text/* MIME types Firefox doesn't support, and I am not aware that one can change the profile from the sandbox (that would be a security issue). BTW, I've just seen that the problem is mentioned in this comment of Issue 3226. Now, using the "emacs" profile would not even be a good idea because my home directory would no longer be protected, in case of a security issue in Emacs that the viewed file could exploit. Ideally, Emacs should run with even more restrictions: for instance, it doesn't need to access the .mozilla directory to view the file.

Concerning /usr/share/emacs, it is already whitelisted in my firefox-common.local file (this was already needed before GNU Emacs 28, but the /usr/libexec thing is new in GNU Emacs 28).

I don't see why blacklist /usr/libexec would be specific to Firefox. IMHO, if it is there for a reason for Firefox, this should also be the case for the other web browsers (and in case some particular web browser would need to access /usr/libexec for its own use, then its particular profile should have noblacklist /usr/libexec).

Create a new profile, such as "webbrowser-common.profile" and include it in the .local profile of every web browser that you use

This is precisely what I want to avoid, because I don't want to remember to update my configuration for future web browsers I will use. BTW, firejail currently has this issue, making the web-browser profiles inconsistent: why isn't /usr/libexec blacklisted for the Opera web browser ("opera" profile)?

It seems that firefox-common.profile contains things that are actually common to every web browser. So shouldn't firefox-common.profile actually by named webbrowser-common.profile and be included by all the web-browser profiles?

[glitsj16]

Besides, emacs has it's own dedicated profile and running it in the firefox sandbox is also your decision.
It is not my decision. It is Firefox that runs Emacs (as an helper application) for text/* MIME types Firefox doesn't support, and I am not aware that one can change the profile from the sandbox (that would be a security issue).

I was confused by this from the beginning I guess. Personally I've never experienced any problems with text/* file handling in a sandboxed Firefox. Now I realize that's due to my settings and personal workflow. I open them in FF or save them to ${DOWNLOADS} and open them via CLI and/or GUI file manager with whatever app is needed, running in its own dedicated sandbox. It's a habit I suppose. Can you provide a link to a file somewhere you always open with emacs?

I don't see why blacklist /usr/libexec would be specific to Firefox.
This is precisely what I want to avoid, because I don't want to remember to update my configuration for future web browsers I will use. BTW, firejail currently has this issue, making the web-browser profiles inconsistent: why isn't /usr/libexec blacklisted for the Opera web browser ("opera" profile)?

That's the thing. IMO this is a distro/packaging issue. Some use /usr/libexec, some don't. Those that do don't just put all executables that make up an application in that location, but also use /usr/bin. This is the commit that added blacklist /usr/libexec to firefox.profile (and several others). Not sure what the exact rationale was at the time.

It seems that firefox-common.profile contains things that are actually common to every web browser. So shouldn't firefox-common.profile actually by named webbrowser-common.profile and be included by all the web-browser profiles?

IMO this whole discussion hints at manageability of the profiles and where one would draw the line, which is bound to be always somewhat subjective. Sure there is overlap, and on face-value having a webbrowser-common.profile does sound attractive. I'm not against that on principle. I'm just worried about the rising complexities of the profiles in general. Tracking all the options for a specific application is becoming more complex, and cutting corners, making semantic changes IMO conveys a false sense of security, which we shouldn't take lightly.

[kmk3]

@vinc17fr commented on Aug 25:

Replying to the last two comments:

Besides, emacs has it's own dedicated profile and running it in the firefox
sandbox is also your decision.

It is not my decision. It is Firefox that runs Emacs (as an helper
application) for text/*
MIME types Firefox doesn't support, and I am not aware that one can change
the profile from the sandbox (that would be a security issue). BTW, I've just
seen that the problem is mentioned in this comment of Issue
3226.
Now, using the "emacs" profile would not even be a good idea because my home
directory would no longer be protected, in case of a security issue in Emacs
that the viewed file could exploit.

I'm afraid that there is currently no firejail-only solution to this that does
not involve allowing more things in the web browser profiles.

There is xdg-open, which was made precisely for this use case, though it
depends on dbus, which is a vector for potentially escaping the sandbox. But
if the main priority is to avoid managing the web browser profiles, this is
probably it.

Ideally, Emacs should run with even more restrictions: for instance, it
doesn't need to access the .mozilla directory to view the file.

Yes, but as mentioned in #3226, there is currently no way to do such a
transition in firejail. Maybe with Landlock support and a lot of work it
would be possible eventually, at least for filesystem paths.

Concerning /usr/share/emacs, it is already whitelisted in my
firefox-common.local file (this was already needed before GNU Emacs 28, but
the /usr/libexec thing is new in GNU Emacs 28).

I don't see why blacklist /usr/libexec would be specific to Firefox. IMHO,
if it is there for a reason for Firefox, this should also be the case for the
other web browsers (and in case some particular web browser would need to
access /usr/libexec for its own use, then its particular profile should
have noblacklist /usr/libexec).

BTW, firejail currently has this issue, making the web-browser profiles
inconsistent: why isn't /usr/libexec blacklisted for the Opera web browser
("opera" profile)?

Good question. As said above, it looks like these restrictions were first
added on commit 459a186 ("Restrict /usr/libexec", 2021-05-19) / PR #4287.

@rusty-snake Is this something that could be added to an existing include? Or
is it something that would be its own include but isn't because it's only one
line?

Create a new profile, such as "webbrowser-common.profile" and include it in
the .local profile of every web browser that you use

This is precisely what I want to avoid, because I don't want to remember to
update my configuration for future web browsers I will use.

It seems that firefox-common.profile contains things that are actually
common to every web browser. So shouldn't firefox-common.profile actually
by named webbrowser-common.profile and be included by all the web-browser
profiles?

No; see chromium-common.profile and the profiles for TUI browsers, such as
lynx.profile. Maybe the common parts of firefox-common.profile and
chromium-common.profile could be extracted into a new profile, but @glitsj16's
comment about manageability should be noted in this case.

And even if the name were changed, it would still be included at the end of
profiles, because it's a common profile and so overrides to the common settings
should be set beforehand.

See the usual structure of a profile that includes a -common profile:

include foo.local           # user's profile-specific overrides
include globals.local       # user's global overrides 
# [...]                     # profile-specific includes/commands
include bar-common.profile  # common includes/commands for bar profiles

Additionally, note that the primary purpose of -common profiles is not user
customization, but to avoid having to repeat the same code on multiple profiles
upstream.

From the user's perspective, a -common profile can used as a common
"post-profile hook", so to speak and so maybe there could be a common
"pre-profile hook".

The question then becomes one of usability/organization/maintenance.

For example, including firefox-pre-common.profile at the beginning and
firefox-post-common.profile at the end.

Though that does not include every browser. So maybe webbrowser-common.profile
+ firefox-common.profile. Which might be too generic, as people probably use
TUI and GUI browsers in different contexts.

So use either webbrowser-tui-common.profile or webbrowser-gui-common.profile +
firefox-common.profile. Then people might want to do the same for other
profiles, such as email-common.profile.

And so on and so forth.

All of which increase complexity and potential for confusion (for example, "why
does this profile include an empty profile?").

So again, I'd go with either xdg-open or with overriding the .local for every
browser that you use.

[rusty-snake]

Is this something that could be added to an existing include? Or is it something that would be its own include but isn't because it's only one
line?

One line isn't a include thing. I'm even against all short includes (3-5 lines) but we don't have aliases/macros yet.

[kmk3]

So as mentioned, the main purpose of firefox-common.profile is to organize
the code and whatever customization benefits it (and firefox-common.local)
provide are incidental, so marking this as "notabug".

Other ways of resolving the issue at hand were posted and there hasn't been any
more activity about the main issue for about a week, so I'm closing this.

Feel free to post any updates or request to reopen if you have more questions.