Bug#1098869: apparmor: triggers a security warning in Firefox - broken firefox profile?

[Vincent Lefevre]

Package: apparmor
Version: 4.1.0~beta5-2
Severity: important

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

-- System Information:
Debian Release: trixie/sid
APT prefers unstable-debug
APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable-debug'), (500, 'proposed-updates-debug'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.11.10-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages apparmor depends on:
ii debconf [debconf-2.0] 1.5.89
ii libc6 2.40-7

apparmor recommends no packages.

Versions of packages apparmor suggests:
pn apparmor-profiles-extra <none>
pn apparmor-utils <none>

-- debconf information:
apparmor/homedirs:

[Vincent Lefevre]

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

Post by Vincent Lefevre
After the apparmor upgrade to 4.1.0~beta5-2, Firefox
(Debian's package firefox 135.0.1-1) now displays the
Some of Firefox's security features may offer less protection
on your current operating system.

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.

[Vincent Lefevre]

Control: affects -1 firejail

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

Post by Vincent Lefevre

Post by Vincent Lefevre
After the apparmor upgrade to 4.1.0~beta5-2, Firefox
(Debian's package firefox 135.0.1-1) now displays the
Some of Firefox's security features may offer less protection
on your current operating system.

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.

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

[intrigeri]

Control: tag -1 + moreinfo

Hi,

Post by Vincent Lefevre

Post by Vincent Lefevre
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.

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

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

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,

[Vincent Lefevre]

Hi,

Post by intrigeri

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

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?

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

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

After restoring the firejail-default AppArmor profile, this revert
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,

[intrigeri]

Control: reassign -1 firejail
Control: retitle -1 firejail-default AppArmor profile needs userns rule

Hi,

Post by Vincent Lefevre

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

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

Perfect, thanks. So I'm reassigning this bug to firejail, where this
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).

Post by Vincent Lefevre

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

After restoring the firejail-default AppArmor profile, this revert
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.

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,