[GH-ISSUE #6675] Firefox warning message about user namespace after upgrade to AppArmor 4

gitea-mirror commented

2026-05-05 09:55:09 -06:00

Owner

Originally created by @vinc17fr on GitHub (Mar 4, 2025).
Original GitHub issue: https://github.com/netblue30/firejail/issues/6675

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.

Originally created by @vinc17fr on GitHub (Mar 4, 2025). Original GitHub issue: https://github.com/netblue30/firejail/issues/6675 ### 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  - [x] The issues is caused by firejail (i.e. running the program by path (e.g. `/usr/bin/vlc`) "fixes" it). - [x] I can reproduce the issue without custom modifications (e.g. globals.local). - [x] The program has a profile. (If not, request one in `https://github.com/netblue30/firejail/issues/1139`) - [x] The profile (and redirect profile if exists) hasn't already been fixed [upstream](https://github.com/netblue30/firejail/tree/master/etc). - [x] I have performed a short search for similar issues (to avoid opening a duplicate). - [x] I'm aware of `browser-allow-drm yes`/`browser-disable-u2f no` in `firejail.config` to allow DRM/U2F in browsers. ### Log <details> <summary>Output of <code>LC_ALL=C firejail /path/to/program</code></summary> <p> ``` 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 ``` </p> </details> <details> <summary>Output of <code>LC_ALL=C firejail --debug /path/to/program</code></summary> <p> I can see in particular: ``` noroot user namespace installed ``` and ``` AppArmor enabled ``` I can provide the full output if needed. </p> </details>

gitea-mirror commented

2026-05-05 09:55:11 -06:00

Author

Owner

@SjoerdV commented on GitHub (Mar 27, 2025):

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

@SjoerdV commented on GitHub (Mar 27, 2025): 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

gitea-mirror commented

2026-05-05 09:55:12 -06:00

Author

Owner

@rusty-snake commented on GitHub (Mar 27, 2025):

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.

@rusty-snake commented on GitHub (Mar 27, 2025): > 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.

gitea-mirror commented

2026-05-05 09:55:13 -06:00

Author

Owner

@SjoerdV commented on GitHub (Mar 28, 2025):

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.

@SjoerdV commented on GitHub (Mar 28, 2025): > 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.

gitea-mirror commented

2026-05-05 09:55:14 -06:00

Author

Owner

@rusty-snake commented on GitHub (Mar 28, 2025):

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).

@rusty-snake commented on GitHub (Mar 28, 2025): > 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).

gitea-mirror commented

2026-05-05 09:55:15 -06:00

Author

Owner

@SjoerdV commented on GitHub (Mar 29, 2025):

@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.

@SjoerdV commented on GitHub (Mar 29, 2025): @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.

gitea-mirror commented

2026-05-05 09:55:15 -06:00

Author

Owner

@rusty-snake commented on GitHub (Mar 29, 2025):

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.

@rusty-snake commented on GitHub (Mar 29, 2025): > 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.

gitea-mirror commented

2026-05-05 09:55:16 -06:00

Author

Owner

@SjoerdV commented on GitHub (Mar 30, 2025):

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?

@SjoerdV commented on GitHub (Mar 30, 2025): > 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?

gitea-mirror commented

2026-05-05 09:55:16 -06:00

Author

Owner

@rusty-snake commented on GitHub (Mar 30, 2025):

(Still replying in context of https://github.com/netblue30/firejail/issues/6675#issuecomment-2764227777)

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.

@rusty-snake commented on GitHub (Mar 30, 2025): (Still replying in context of https://github.com/netblue30/firejail/issues/6675#issuecomment-2764227777) 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.

gitea-mirror commented

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

Author

Owner

@SjoerdV commented on GitHub (Mar 31, 2025):

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)

@SjoerdV commented on GitHub (Mar 31, 2025): 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)

gitea-mirror commented

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

Author

Owner

@rusty-snake commented on GitHub (Mar 31, 2025):

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.

@rusty-snake commented on GitHub (Mar 31, 2025): 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`.

gitea-mirror commented

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

Author

Owner

@SjoerdV commented on GitHub (Apr 1, 2025):

Ok so I found out using AA and FJ together is pretty awkward and not generally a good idea.
https://github.com/netblue30/firejail/issues/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?)
https://github.com/netblue30/firejail/issues/2291#issuecomment-445219818

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!

@SjoerdV commented on GitHub (Apr 1, 2025): Ok so I found out using AA and FJ together is pretty awkward and not generally a good idea. https://github.com/netblue30/firejail/issues/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?) https://github.com/netblue30/firejail/issues/2291#issuecomment-445219818 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!

gitea-mirror commented

2026-05-05 09:55:18 -06:00

Author

Owner

@duckduck1 commented on GitHub (Apr 10, 2025):

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.

@duckduck1 commented on GitHub (Apr 10, 2025): > 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](https://wiki.archlinux.org/title/Firejail#Enable_AppArmor_support) 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.

gitea-mirror commented

2026-05-05 09:55:18 -06:00

Author

Owner

@SjoerdV commented on GitHub (Apr 11, 2025):

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.

@SjoerdV commented on GitHub (Apr 11, 2025): 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.

gitea-mirror commented

2026-05-05 09:55:19 -06:00

Author

Owner

@vinc17fr commented on GitHub (Apr 11, 2025):

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.

@vinc17fr commented on GitHub (Apr 11, 2025): > Then the other way to allow userns (besides the one [@duckduck1](https://github.com/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`.

gitea-mirror commented

2026-05-05 09:55:19 -06:00

Author

Owner

@Sebb65 commented on GitHub (Nov 12, 2025):

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.

I did that on my Debian 13 system.

I created a copy of the firejail-default apparmor profile, with just a different name (firejail-userns) and the userns option added.

Now I can choose that specific AA profile on the command line:
firejail --profile=firefox-esr --apparmor=firejail-userns firefox-esr
or inside a firejail profile:
apparmor firejail-userns

Important: this option needs to be parsed after the apparmor option from the bundled firefox profile (or modify the bundled profile).

@Sebb65 commented on GitHub (Nov 12, 2025): > 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`. I did that on my Debian 13 system. I created a copy of the firejail-default apparmor profile, with just a different name (firejail-userns) and the userns option added. Now I can choose that specific AA profile on the command line: `firejail --profile=firefox-esr --apparmor=firejail-userns firefox-esr` or inside a firejail profile: `apparmor firejail-userns` Important: this option needs to be parsed after the apparmor option from the bundled firefox profile (or modify the bundled profile).

gitea-mirror commented

2026-05-05 09:55:20 -06:00

Author

Owner

@vinc17fr commented on GitHub (Nov 13, 2025):

Doing a copy of a profile is not a good thing because in case of update of the original profile, this will not be propagated to the new profile. It seems that the right thing is to provide the common rules for firejail as an abstraction (e.g. /etc/apparmor.d/abstractions/firejail).

@vinc17fr commented on GitHub (Nov 13, 2025): Doing a copy of a profile is not a good thing because in case of update of the original profile, this will not be propagated to the new profile. It seems that the right thing is to provide the common rules for firejail as an abstraction (e.g. `/etc/apparmor.d/abstractions/firejail`).

gitea-mirror commented

2026-05-05 09:55:20 -06:00

Author

Owner

@mYnDstrEAm commented on GitHub (Dec 17, 2025):

Having the same problem and asked about it here before I found this issue.

Is a change by apparmor to provide a second profile for firefox (with the userns option added) needed to fix this and if so, could you please create the issue about this here? If not, could somebody please summarize the outcomes so far of the discussion above?

The current workaround seems to be

sudo cp /usr/share/apparmor/extra-profiles/firefox /etc/apparmor.d/firefox
editing /etc/apparmor.d/firefox to append userns to the bottom
editing ~/.config/firejail/firefox.local to append apparmor firejail-userns to the bottom
These steps probably have some error so I suggest somebody details the exact steps needed for the workaround.

Should one implement that workaround for security or is that not really needed?

@mYnDstrEAm commented on GitHub (Dec 17, 2025): Having the same problem and asked about it [here](https://unix.stackexchange.com/questions/803054/firefox-warning-on-debian-13-some-of-firefox-s-security-features-may-offer-les) before I found this issue. Is a change by apparmor to provide a second profile for firefox (with the userns option added) needed to fix this and if so, could you please create the issue about this here? If not, could somebody please summarize the outcomes so far of the discussion above? The current workaround seems to be * `sudo cp /usr/share/apparmor/extra-profiles/firefox /etc/apparmor.d/firefox` * editing /etc/apparmor.d/firefox to append `userns` to the bottom * editing `~/.config/firejail/firefox.local` to append `apparmor firejail-userns` to the bottom These steps probably have some error so I suggest somebody details the exact steps needed for the workaround. Should one implement that workaround for security or is that not really needed?