1888989 - Linux Sandbox features (AppArmor user namespaces) silently disabled for some installation methods without any warning

Status: RESOLVED DUPLICATE of bug 1899516

(Core :: Security: Process Sandboxing, defect, P2)

Description

[QwertyChouskie]

User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/113.0.5666.197 Safari/537.36

Steps to reproduce:

In https://bugzilla.mozilla.org/show_bug.cgi?id=1884347 a check was added to see if the distro being ran on blocks AppArmor user namespace creation, and if so, disables the Firefox sandbox functionality that uses this feature.

From comment 7 (https://bugzilla.mozilla.org/show_bug.cgi?id=1884347#c7):

Regardless whether we can detect this or not, if they disabled user namespaces this means we lose part of our sandboxing layer. What's crazy here is that some other distros did that earlier, then reverted the restriction as the kernel layer got better debugged (Arch comes to mind). So we thought we could rely on this but now Ubuntu has regressed again and moved in the opposite direction. Sigh.

From comment 20 (https://bugzilla.mozilla.org/show_bug.cgi?id=1884347#c17):

(In reply to Jed Davis [:jld] ⟨⏰|UTC-7⟩ ⟦he/him⟧ from comment #8)

It's reported that Snap and Flatpak packaged browsers aren't affected, because both of those package systems apply their own sandboxes which block user namespace creation, so we presumably don't get far enough to encounter whatever is going on with AppArmor.

This isn't quite right. Flatpak blocks our use of namespaces, but Snap allows it (verified by looking at about:support#sandbox); however, Snap seems to have its own AppArmor integration, so we're presumably not getting the default unprivileged-unconfined settings in that case.

Also, due to the policy declared in the /etc/apparmor.d/firefox file in Ubuntu 24.04's apparmor package, Mozilla's experimental .deb package of the Release branch isn't affected (thanks to gcp for noticing that), but the Beta/DevEdition/Nightly packages are affected (because the file pattern in the policy doesn't match their executables).

The problem is that the solution to the bug was to disable the part of Firefox's sandboxing layer that uses user namespaces without any warning as to it being disabled. It also seems to be indicated that the Flatpak build of Firefox has had these sandbox functions disabled for quiet some time.

Any circumstance where an important component of Firefox's sandbox is disabled should have some sort of warning to the user, and potentially even prevent launching unless the issue is fixed or the user overrides the warning.

Maybe I'm overly paranoid, but after the xz-utils incident, I am extremely wary of any type of change that silently weakens security. Maybe the disabled feature isn't actually important, but better to report what might be a non-issue than not report what might be a real issue.

Comment 1

[Daniel Veditz [:dveditz]]

Jed: Is this downgrading reflected in our about:support page? The sandbox info there is pretty minimal, but there's a "Content Process Sandbox Level" and "Effective Content Process Sandbox Level". The levels are arbitrary and won't mean anything to users, but would this downgrade even be reflected by a difference in those numbers? Some folks might notice that and wonder why, at least.

Improving the level of detail or comprehensibility on about:support seems like a good place to start.

A user-facing notification or announcement is more problematic. Is it a one-time popup? People will miss it. Is it there all the time? Boy, are people going to get annoyed. And mad if we're telling them to fix something they can't figure out or don't have the permissions to do. Maybe an addition to something like an entry on "About Firefox" would strike a balance, or a notification in about:preferences (we've done that for some commonly-hijacked settings in the past)

Although this issue impacts security, I don't think it needs to be hidden. One instance of the issue is public in bug 1884347, and new UI involves designers and translators and is impractical to keep private.

Comment 2

[Gian-Carlo Pascutto [:gcp]]

about:support will give User Namespaces as false instead of true. The sandbox level won't change, as the different features are more like bitflags than levels and the levels reflect what combinations we tested to work correctly - not necessarily what effectively does anything on your underlying distro/kernel, because as the past has shown, distros can randomly disable or break security features (it's pure luck Ubuntu's change crashed us to begin with thus signaling something was wrong).

Some folks might notice that and wonder why, at least.

We could make the User Namespaces line be yellow instead of just false to signal that this is something the user could try to fix on their configuration. Media does it for codec support.

potentially even prevent launching unless the issue is fixed or the user overrides the warning

The affected people are those who did a manual install without using our deb packages or whatever Ubuntu ships, so dumping a warning to the command line and refusing to start without overrule would be reasonable. But it's a nightmare for upgrade scenarios: you upgrade your Ubuntu to 24.04 and suddenly Firefox stops working. There's no guarantee you ever see the warning if you're using a desktop shortcut - that feels like a severe issue for what is a defense in depth feature (as explained in the other bugs, you're still sandboxed without this, which is a difference from other browsers).

A user-facing notification or announcement is more problematic.

I agree, this is an UX nightmare: https://bugzilla.mozilla.org/show_bug.cgi?id=1884347#c22. It's an obscure detail of Linux security internals, it requires a per-distro explanation of how to fix, and we may not be able to reliably diagnose the cause from within Firefox itself, so linking to some huge SUMO page is probably the best we can do. Even the message in the New Tab/First Run Page has serious issues, for example if it's not actionable by the user (if they're not the sysadmin of the system).

From my perspective this is 100% a distro issue, but of course Ubuntu is just going to go 🙈 🙉 because their packages and Snap work correctly.

Based on this, making the warning in about:support more prominent with colors feels like the best we can do for now. (There's a whole other discussion whether the underlying Linux feature can't be reworked to enable the limited features desktop needs while hammering down the server use case more - instead of killing it with a sledgehammer - but with only the browsers making much use of it, I'm not sure we're going to see a lot of movement)

Comment 3

[Brian Tsoi [:btsoi]]

Made new bug for line color change

Comment 4

[Gian-Carlo Pascutto [:gcp]]

I think bug 1899516 makes us "loud" enough that we can consider this fixed.