Firefox warning message about user namespace after upgrade to AppArmor 4

[vinc17fr]

Description

Since the upgrade to AppArmor 4 on Debian/unstable, Firefox displays the following warning message: "Some of Firefox's security features may offer less protection on your current operating system."

And there is a link to https://support.mozilla.org/en-US/kb/install-firefox-linux#w_security-features-warning

In particular:

The sandbox in Firefox makes use of unprivileged user namespaces when creating new processes for enforcing more security. This can be considered a security risk, therefore some Linux distributions have started to restrict its usage and only allow it to work where there is an AppArmor profile.

So the Firefox AppArmor profile has userns to allow user namespaces.

The issue is that with Firejail, the AppArmor profile is firejail-default, not the Firefox one, thus it does not have userns.

Steps to Reproduce

Run firejail /usr/bin/firefox and continue until a Firefox browser window is open.

Expected behavior

The Firefox window should not show a warning message.

Actual behavior

The following warning message is shown above the main area: "Some of Firefox's security features may offer less protection on your current operating system."

Behavior without a profile

What changed calling LC_ALL=C firejail --noprofile /path/to/program in a
terminal?

There is no warning message. But I suppose that this is because the firefox profile uses AppArmor (which is probably wanted), according to the contents of the firefox-common.profile file:

apparmor
# Fixme!
apparmor-replace

while this is not the case without a profile.

Additional context

My Debian bug report: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1098869

This may be similar to #6368 for Chromium.

Environment

• Name/version/arch of the Linux kernel (uname -srm): Linux 6.11.10-amd64 x86_64
• Name/version of the Linux distribution (e.g. "Ubuntu 20.04" or "Arch Linux"): Debian/unstable
• Name/version of the relevant program(s)/package(s) (e.g. "firefox 134.0-1,
  mesa 1:24.3.3-2"): Firefox 135.0.1
• Version of Firejail (firejail --version): 0.9.72

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.

Log

Output of LC_ALL=C firejail /path/to/program

Reading profile /etc/firejail/firefox.profile
Reading profile /home/vlefevre/.config/firejail/firefox.local
Reading profile /etc/firejail/whitelist-usr-share-common.inc
Reading profile /etc/firejail/firefox-common.profile
Reading profile /home/vlefevre/.config/firejail/firefox-common.local
Reading profile /etc/firejail/disable-common.inc
Reading profile /etc/firejail/disable-devel.inc
Reading profile /etc/firejail/disable-exec.inc
Reading profile /etc/firejail/disable-interpreters.inc
Reading profile /etc/firejail/disable-proc.inc
Reading profile /etc/firejail/disable-programs.inc
Reading profile /etc/firejail/whitelist-common.inc
Reading profile /etc/firejail/whitelist-run-common.inc
Reading profile /etc/firejail/whitelist-runuser-common.inc
Reading profile /etc/firejail/whitelist-var-common.inc
Warning: networking feature is disabled in Firejail configuration file
Seccomp list in: !chroot, check list: @default-keep, prelist: unknown,
Parent pid 142128, child pid 142132
Warning: An abstract unix socket for session D-BUS might still be available. Use --net or remove unix from --protocol set.
Warning: NVIDIA card detected, nogroups command ignored
Warning: NVIDIA card detected, nogroups command ignored
Warning: NVIDIA card detected, nogroups command ignored
Warning: NVIDIA card detected, nogroups command ignored
Warning: NVIDIA card detected, nogroups command ignored
Warning: NVIDIA card detected, nogroups command ignored
Seccomp list in: !chroot, check list: @default-keep, prelist: unknown,
Warning: NVIDIA card detected, nogroups command ignored
Warning: NVIDIA card detected, nogroups command ignored
Warning: Replacing profile instead of stacking it. It is a legacy behavior that can result in relaxation of the protection. It is here as a temporary measure to unbreak the software that has been broken by switching to the stacking behavior.
Child process initialized in 460.94 ms
[GFX1-]: RenderCompositorSWGL failed mapping default framebuffer, no dt

Output of LC_ALL=C firejail --debug /path/to/program

I can see in particular:

noroot user namespace installed

and

AppArmor enabled

I can provide the full output if needed.

[SjoerdV]

I think a discussion is in order if it is truly 'secure' or 'desirable' to give a browser access to userns. Examples are available where those namespaces are subject to privilege escalation attacks.
So personally I would just rely on the stricter sandbox firejail already provides as going the Mozilla route involves whitelisting userns in the firejail apparmor profile. Any comments from @netblue30 would be appreciated

[rusty-snake]

the stricter sandbox firejail

Firefox's internal sandbox is much stricter than the theatre firejail applies.

I think a discussion is in order if it is truly 'secure' or 'desirable' to give a browser access to userns. Examples are available where those namespaces are subject to privilege escalation attacks.

Of course more permissions is less secure. If you would deny network access for your browser it is much more secure, but some things are necessary. And granting userns is more secure than breaking the internal sandbox.

[SjoerdV]

Firefox's internal sandbox is much stricter than the theatre firejail applies.

Probably comparing 🍎 with 🍊
The internal FF sandbox protects websites/tabs from each other within the App. Firejail protects the OS from the App. I prefer an uncompromising stance for the latter. And the 'theater' is only exposed if Apps build code strictly designed to circumvent the firejail sandbox. Such an app would of course loose all credibility for sure.

granting userns is more secure than breaking the internal sandbox.

That is your opinion, don't state as fact please. But I invite you to elaborate on the why, by providing reasons to weaken the outer sandbox for the benefit of the internal one.

[rusty-snake]

The internal FF sandbox protects websites/tabs from each other within the App.

50%, it also protects the host from the web content. You can not protect the horizontal path without protecting the vertical path.

That is your opinion, don't state as fact please. But I invite you to elaborate on the why, by providing reasons to weaken the outer sandbox for the benefit of the internal one.

TL;DR: The internal sandbox isolates the most dangerous part, web-content (Untrusted input and untrusted code (JS/Wasm) processed by an unsafe language), in a strict sandbox. The outer sandbox is already weaker and has more escape vectors.

So what are the reasons to block user namespaces:

• direct sandbox escape? No
• exploit protection? No
• minimized permissions? It's complicated, Yes and No
• (kernel) attack surface reduction? Yes, that's the main point
• more specific sandbox-permissions models like in flatpak? Do not apply to us
  • The firefox flatpak has no access to (raw) user namespaces because the flatpak permission model does not allow it. User namespaces aren't the top most important part of firefox internal sandbox so this isn't a nigthmare. But we are not flatpak, we can allow it.

So attack surface reduction. What looks the overall attack surface of firefox.profile like? Huge.
What looks the overall attack surface of firefox internal sandbox? Small(er).

So you ask for the reasons to allow it:

• allow an even stricter internal sandbox (see TL;DR).

[SjoerdV]

@rusty-snake thanks for your effort in explaining userns and the inclusion of flatpak in your comparison.

However I am still not convinced Firefox is the best candidate App to allow userns for, as it can come in direct contact with some very unsavory sites and therefore poses a real risk to the containing system if it were to be allowed to execute elevated/root actions (even within the sandbox!) as it now comes in direct contact with the kernel.

Furthermore just a couple of days ago no less than 3 userns vulnerabilities were published. And I guess more can be expected.

https://www.qualys.com/2025/three-bypasses-of-Ubuntu-unprivileged-user-namespace-restrictions.txt

So I am still inclined to have especially and specifically Firefox remain a dumb 'regular user' app without the possibility to create sandboxes of its own.

I hope more people can chip in and give points of view.

[rusty-snake]

https://www.qualys.com/2025/three-bypasses-of-Ubuntu-unprivileged-user-namespace-restrictions.txt

Well, these are vulnerabilities in the userns blocking of Ubuntu.

Going into that a bit, Ubuntu tries to block userns by default for all programs and then transitions from blocked to allowed. Something like this is incredible difficult to be done right. I'm not deep in AppArmor so I can not explain in depth here, but to give na practical example: Ubuntu allows userns creation in the AA profile of flatpak (technical requirement of flatpak/bwrap). However, flatpak isn't designed to "isolate" this permission. Meaning if a program is not allowed to create userns but is allowed to flatpak run com.example.App, it would be rather simple AFAIK to somehow capture the userns created by flatpak.

[SjoerdV]

these are vulnerabilities in the userns blocking of Ubuntu

...AND after that allow an unprivileged user to gain full administrative capabilities within a user namespace.

So just the fact there are CVEs trying to circumvent ubuntu's user namespace restrictions would mean in my book that not having these restrictions at all (like in debian or arch) is just naïve.

But OK, let's assume that even with administrative permissions in the sandbox the system is still 'safe' as long there is no kernel exploit to escape the sandbox.

Is there a way that the system, while also using firejail, can apply the specially crafted AA FF profile instead of the firejail-default one with userns, added?

[rusty-snake]

(Still replying in context of #6675 (comment))

Let's talk a bit about sandbox architectures. There are fundamental two approaches for sandbox architecture: wrapper sandboxes and broker sandboxes. Of course there are hybrid concepts, sub-approaches, …. A wrapper sandbox sets up a confined environment and hands off control to the sandboxee. A broker sandbox (in it's strictest form) starts the sandboxee in an empty environment with only cpu time, memory and an IPC interface to the broker (seccomp mode 1 is an example of a very strict implementation). Every impure operation/access must go through the broker.

firejail falls into the wrapper sandbox category. The greatest advantage of a wrapper sandbox is that it can be applied to every code because it needs zero cooperation of the sandboxed code. The greatest disadvantage is that it need to grant every permission any module of the sandboxed code could ever need. A broker sandbox on the other hand can perform runtime checks and grant/revoke permissions only to/from specific modules, at specific times, after user consent, …. And if the sandboxed code cooperates with the broker, it can assign different trust levels to different modules / provided sandboxed APIs.

That being said means that the internal sandbox of Firefox/Chromium/…, which is broker based, can

• replace insecure APIs like X11 or PulseAudio with sandboxed APIs (i.e. the WebContent-Process talks to the broker which then translates (filtered) to X11/PulseAudio/...).
• Grante/Revoke permissions dynamically as needed.
• Isolate the most untrusted parts (WebContent) to virtually nothing
  • empty/micromal filesystem
  • no/minimal network access (only preconnected TCP sockets)
  • no user namespaces
  • minimal syscalls
  • ...
  • while keeping convenient file:/// access for the user working

i.e. the internal sandbox is in the better position. First because it can draw the line between Firefox-UI/about:profiles/... and WebContent_untrusted-example.com, where firejail can only draw the line between Firefox (everything) and "the host" (i.e. Firefox (not to confuse with WebContent) has no access to some folders in $HOME). Second because the sandboxed code cooperates with the sandboxer which means it can replace insecure APIs. This is impossible for firejail. Third because it can use runtime state to dynamically create more granular sandboxes.

[SjoerdV]

Great write-up, much appreciated!

Reading all this makes me appreciate the double sandbox (wrapper (by FJ) & broker (within FF) even more.

My question was about where AppArmor (AA) comes in to play and if it was possible to redirect the wrapper sandbox to use the AA profile for the specific App being used. Then we would have the best of three worlds (outer FJ sandbox with child (FF) AppArmor restrictions AND the internal FF sandbox)

[rusty-snake]

I'm on a SELinux system for years now and have not much contact points to AA so I can not help very much here. Nevermind, you should have a look at the firejail manpage for apparmor and apparmor-replace.

[SjoerdV]

Ok so I found out using AA and FJ together is pretty awkward and not generally a good idea.
#2248
And defining 'App specific' AA profiles within the firejail-default AA profile is not possible (or is there an update since Dec 7, 2018?)
#2291 (comment)

So ideally (if I put things together right) we would need a custom
/$HOME/.config/firejail/firefox.local (relaxed profile with only secomp filtering and networking)
AND
/etc/apparmor.d/local/firefox (profile with very strict path restrictions and the userns, inclusion that is making all the fuss)

Especially the apparmor profile creation and maintenance I am not looking forward to, but if someone has a baseline for both that could work, that would be awesome. Suggestions are appreciated!

[duckduck1]

My question was about where AppArmor (AA) comes in to play and if it was possible to redirect the wrapper sandbox to use the AA profile for the specific App being used. Then we would have the best of three worlds (outer FJ sandbox with child (FF) AppArmor restrictions AND the internal FF sandbox)

For me on Arch Linux with system wide enabled Unprivileged User Namespaces (kernel.unprivileged_userns_clone = 1) there is no warning message in Firefox with firejail-default profile enforced (firejail --apparmor /usr/bin/firefox). In this configuration Firefox states Sandbox support the same as without Firejail (about:support -> Sandbox -> User Namespaces: true):

Sandbox

Seccomp-BPF (System Call Filtering): true
Seccomp Thread Synchronization: true
User Namespaces: true
Content Process Sandboxing: true
Media Plugin Sandboxing: true
Content Process Sandbox: Level 4
Effective Content Process Sandbox: Level 4

With that configuration there should be full Firefox sandboxing within Firejail/AppArmor with the downside of maintaining kernel attack surface via Unprivileged User Namespaces.

Sadly (at least to my knowledge) there is no way to disable Unprivileged User Namespaces (kernel.unprivileged_userns_clone = 0) but allow it for Firefox only.

The Arch Linux Wiki says there is an discouraged ignore apparmor command when not using firejail-default but a specific app profile is desired. I did not try it though as to my understanding this would not solve the issue that Unprivileged User Namespaces would have to be allowed in the first place.

[SjoerdV]

Ok so I think we can conclude there is no way to allow userns for a specific app only. You either open it up system wide or you don’t.

Then the other way to allow userns (besides the one @duckduck1 describes) is just to add userns, to the ‘firejail-default’ AA profile.

I think I personally prefer this method (ie. having firejail control userns usage) to the kernel setting method. But if someone has great arguments to prefer the later please enlighten.

[vinc17fr]

Then the other way to allow userns (besides the one @duckduck1 describes) is just to add userns, to the ‘firejail-default’ AA profile.

If this is an issue for the other applications, I'm wondering whether firejail could have 2 default AA profiles (but this is a bit more complicated): one with userns, one without it. The selected AA profile would then depend on the firejail profile. For instance, the firefox-based firejail profiles would use the AA profile that has userns, and the other firejail profiles would use the AA profile that does not have userns.