After the apparmor upgrade to 4.1.0~beta5-2, Firefox
(Debian's package firefox 135.0.1-1) now displays the
following warning message:

  Some of Firefox's security features may offer less protection
  on your current operating system.

See attached screenshot.

The link "How to fix this issue" leads to

https://support.mozilla.org/en-US/kb/install-firefox-linux

which says:

  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.

  Such profiles can only cover a limited set of installations paths,
  including Snap and Debian packages. They cannot however cover some
  other use cases, such as tarball installations as well as local
  development builds.

and then explains how to create an apparmor profile (but here, there
is already /etc/apparmor.d/firefox).

Control: retitle -1 apparmor: triggers a security warning in Firefox with firejail

This actually occurs only with firejail (I actually use a wrapper
doing that), e.g.

  firejail /usr/bin/firefox

According to "ps -efZ", it is the firejail-default AppArmor profile
that is used.

... in case something needs to be done on the firejail side.

I suspect that this is because the firejail-default AppArmor profile
does not use "userns" (contrary to the firefox AppArmor profile,
which completely changed).

Hi,

Vincent Lefevre (2025-02-25):

Good to know! I have never looked at how firejail uses AppArmor.

I thought "userns" was a no-op on mainline (read: non-Ubuntu) kernels.
But who knows :) And indeed, it does look like $something is blocking
unprivileged user namespaces. Let's try to figure out what
$something is.

Can you try adding the "userns," line to the firejail-default AppArmor
profile and see if you can reproduce?

Another thing that could be worth trying (independently from the
previous one) is to revert /usr/share/apparmor-features/features to
the previous version i.e. revert the changes from this commit:
https://salsa.debian.org/apparmor-team/apparmor/-/commit/71c0d1bfdd0556cb8466913d65ca4f6fced14b63
Then reboot the system and try to reproduce.

Cheers,

Hi,

This makes the warning disappear, but only after a reboot.
also makes the warning disappear (after a reboot).

And after restoring this file (and a reboot), i.e. going back to the
initial state, the warning reappears as expected.

Note: each time, I created a new Firefox profile to check the presence
of the warning.

Regards,

Hi,

Vincent Lefevre (2025-03-03):
update needs to be applied. I'm not tagging this "patch" because
I don't know what problem this profile is meant to solve and whether
adding this rule is appropriate there.

Context for firejail maintainers: AppArmor 4.1.0~beta5 packages block
userns unless the "userns" rule is in the policy. So the
firejail-default profile now breaks apps that need userns (in some
cases, only partly, like in this one).

Good, thank you. Now I understand how the combination of recent kernel
+ updated pinned feature set + outdated policy works wrt. userns.
Thankfully there's a trivial fix that can be applied to any affected
policy so I'm confident it'll all be fixed in time for Trixie. If it
turns out to be significantly more complicated, we can revert the
update of the pinned feature set which should make this whole class of
regressions disappear (at the cost of not gaining the corresponding
security improvement).

Cheers,

Control: forwarded -1 https://github.com/netblue30/firejail/issues/6675

I've just reported the bug upstream.