Closed Bug 1884347 Opened 2 months ago Closed 1 month ago

AppArmor user namespace creation restrictions cause many applications (including Firefox tabs) to crash with SIGTRAP or SIGSEGV

Categories

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

Firefox 125
Desktop
Linux
defect

Tracking

()

VERIFIED FIXED
125 Branch
Tracking Status
relnote-firefox --- 124+
firefox-esr115 --- verified
firefox123 --- wontfix
firefox124 + verified
firefox125 + verified

People

(Reporter: Valeryan_24, Assigned: jld)

References

Details

Attachments

(3 files)

Steps to reproduce:

Hi, there is a major bug on Ubuntu related to ApArmor :
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/2046844/comments/3

Actual results:

An upload was made in AppArmor that no longer allows unprivileged programs to create user namespaces. As it turns out, some browsers like Epiphany, Falkon, and qutebrowser all use these features. When something tries to create a user namespace and fails, apparently it can result in a SIGTRAP pretty quickly.

Since a few days, Firefox worked fine, but with the last updates (both for Firefox and Ubuntu / AppArmor), it doesn' t anymore : the program well launches and starts, but no tab loads, all of them crash, even the about:blank one !

Trying to restore the tab doesn't work.

I see it on Firefox Nightly 125.0a1 from Mozilla deb repositery, other user reported it on "normal" Firefox :
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/2046844/comments/52

Expected results:

Tabs should load normally

OS: Unspecified → Linux
Hardware: Unspecified → Desktop
Summary: AppArmor user namespace creation restrictions cause many applications to crash with SIGTRAP → AppArmor user namespace creation restrictions cause many applications (including Firefox tabs) to crash with SIGTRAP

It seems to only affect tabs of appimage, deb and local/portable Firefox (and Firefox-based browsers), as well as nightly version of Firefox (installed as deb), both in X11 and Wayland sessions - but not flatpak nor snap versions :

https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2056190

I am having the same issue. I hope this is enough to confirm this bug as happening to more than one person.

Component: Untriaged → Security: Process Sandboxing
Product: Firefox → Core

I just updated again, after being gone for the weekend, and still have same result with Firefox v124 beta 9.

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2056297/comments/2 suggests ubuntu deliberately broke this.

Jed, do you know if there's a way we can detect this restriction and avoid crashing here?

Flags: needinfo?(jld)

I've reached out to Canonical via our formal channels.

Jed, do you know if there's a way we can detect this restriction and avoid crashing here?

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.

The suggestion was to ship an AppArmor profile in the deb, but then local development builds are still going to be broken. Might be nasty for the tarball based installs too.

Assignee: nobody → jld
Severity: -- → S2
Priority: -- → P1
Status: UNCONFIRMED → NEW
Ever confirmed: true

See bug 1434528 comment #8 for the last time we ran into this.

In theory, what's supposed to happen is that on startup we attempt this clone call, which creates a new user namespace and attempts to use CAP_SYS_ADMIN within it (because previously we ran into an AppArmor policy that allowed the first of those but not the second and that caused problems), and we set the env var MOZ_ASSUME_USER_NS to cache the result so child processes don't have to repeat such an expensive test. If that test fails, we won't try to use user namespaces but we'll still use seccomp-bpf for sandboxing.

In practice… clearly something is going wrong. According to this bug report the processes are crashing with SIGSEGV — I think the people observing SIGTRAP might be looking at Chromium-based browsers? — and that suggests MOZ_CRASH (a deliberate crash / assertion failure). Unfortunately, MOZ_CRASH doesn't write the crash message to stderr and this is probably happening in a context where our crash reporter doesn't work.

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 (EDIT: see correction in comment #17), so we presumably don't get far enough to encounter whatever is going on with AppArmor.

It's reported that this is 100% reproducible with the 24.04 prerelease version, so maybe I can try to reproduce locally.

Flags: needinfo?(jld)
See Also: → 1434528

As a workaround: setting MOZ_ASSUME_USER_NS=0 in the environment should cause Firefox to, as the variable name suggests, assume that user namespaces aren't available.

Will this affect any extentions, such as shortcut key mappers, that may be installed?

I can now reproduce it in a VM and it's because we're failing to write to /proc/self/uid_map. The command unshare -Unc is roughly similar and fails similarly.

What's weird here is that unshare(CLONE_NEWUSER | CLONE_NEWNET) succeeds, even though the use of CLONE_NEWNET depends on the CAP_SYS_ADMIN granted by the effect of CLONE_NEWUSER, but if clone(CLONE_NEWUSER) and clone(CLONE_NEWNET) are called separately in that order, the second call fails. The last time we had this problem (bug 1434528 comment #8) both of those would fail.

So, I think this is fixable without too much extra code.

(In reply to Guy Schlosser from comment #10)

Will this affect any extentions, such as shortcut key mappers, that may be installed?

It shouldn't affect add-ons; this is a low-level detail which the rest of Firefox generally doesn't care about.

I have partially worked around this bug. I changed the firefox path in /etc/apparmor.d/firefox, to point to /opt/firefox, but when I launch a link from Thunderbird, I still get the tab crash. I can launch though, from the desktop or from the mate menu.

Per gcp, this probably doesn't need to drive an RC respin but we should keep this on the radar for the planned 124 dot release.

See Also: → 1884980
Pushed by jedavis@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/4a6d72cfbc42
Fix unprivileged userns detection to handle new a AppArmor feature. r=gcp

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

Summary: AppArmor user namespace creation restrictions cause many applications (including Firefox tabs) to crash with SIGTRAP → AppArmor user namespace creation restrictions cause many applications (including Firefox tabs) to crash with SIGTRAP or SIGSEGV
Status: NEW → RESOLVED
Closed: 1 month ago
Resolution: --- → FIXED
Target Milestone: --- → 125 Branch

The patch landed in nightly and beta is affected.
:jld, is this bug important enough to require an uplift?

  • If yes, please nominate the patch for beta approval.
  • If no, please set status-firefox124 to wontfix.

For more information, please visit BugBot documentation.

Flags: needinfo?(jld)
See Also: → 1885218

Hi, I confirm that, for Firefox Nightly 125.0a1, version from Mozilla deb repository of 13th March on Ubuntu 24.04, bug is fixed.

Both for tabs opened directly in Firefox, and for links launched from Thunderbird. Thanks !

Duplicate of this bug: 1884593

Bug 1884980 will fix the .deb package, but for people who install the browser from the tarball we have no really good way to notify them that they have to fix their AppArmor security configuration. I think the best suggestion was to pop up a page on first run but that's tricky because it involves quite some UX considerations. Spamming a warning in the console probably won't do much good.

Attachment #9392119 - Flags: approval-mozilla-release?

Uplift Approval Request

  • Steps to reproduce for manual QE testing: Install the Ubuntu 24.04 beta and run the Firefox build from an unpacked tar file (not the .deb package). If it can load the New Tab page then it passes.
  • Fix verified in Nightly: yes
  • Needs manual QE test: yes
  • Is Android affected?: no
  • String changes made/needed: none
  • Explanation of risk level: The patch is contained to this feature detection function, and it should continue to detect all the cases we know about where the OS would block us. And, if there somehow is a regression, it would be immediately obvious on browser startup in QE or Nightly/Beta testing.
  • Code covered by automated testing: no
  • Risk associated with taking this patch: low
  • User impact if declined: On Ubuntu 24.04 the browser will be unable to load any web page, if installed from Mozilla's .tar download (rather than Ubuntu's Snap package, which is the default, or Mozilla's experimental .deb package)
Flags: qe-verify+
Attachment #9392130 - Flags: approval-mozilla-esr115?

Uplift Approval Request

  • Fix verified in Nightly: yes
  • Steps to reproduce for manual QE testing: Install the Ubuntu 24.04 beta and run the Firefox build from an unpacked tar file. If it can load the New Tab page then it passes.
  • String changes made/needed: no
  • Explanation of risk level: The patch is contained to this feature detection function, and it should continue to detect all the cases we know about where the OS would block us. And, if there somehow is a regression, it would be immediately obvious on browser startup in QE or Nightly/Beta testing.
  • Code covered by automated testing: no
  • Needs manual QE test: yes
  • Is Android affected?: no
  • Risk associated with taking this patch: low
  • User impact if declined: On Ubuntu 24.04 the browser will be unable to load any web page, if installed from Mozilla's .tar download (rather than an unofficial .deb package, which might work)
QA Whiteboard: [qa-triaged]

I have reproduced the issue on Firefox 123.0.1 (20240304104836) and verified the fix on Firefox Nightly 125.0a1 (20240313094814).
I will also be back to verify the other FX versions once this gets uplifted.

Attachment #9392119 - Flags: approval-mozilla-release? → approval-mozilla-release+
Attachment #9392130 - Flags: approval-mozilla-esr115? → approval-mozilla-esr115+
See Also: → 1888989

I have also verified the fix on Firefox 124.0.2 (20240328135509) and Firefox 115.10.0 ESR (20240401202613).
Setting the flags accordingly.

Status: RESOLVED → VERIFIED
QA Whiteboard: [qa-triaged]
Flags: qe-verify+
Flags: needinfo?(jld)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: