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

Status: VERIFIED FIXED

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

Description

[Xavier]

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

Comment 1

[Xavier]

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

Comment 2

[[e-mail]]

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

Comment 3

[Guy Schlosser]

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

Comment 4

[Guy Schlosser]

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

Comment 5

[Julien Cristau [:jcristau]]

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?

Comment 6

[Mike Kaply [:mkaply]]

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

Comment 7

[Gian-Carlo Pascutto [:gcp]]

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.

Comment 8

[Jed Davis [:jld] ⟨⏰|UTC-8⟩ ⟦he/him⟧]

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.

Comment 9

[Jed Davis [:jld] ⟨⏰|UTC-8⟩ ⟦he/him⟧]

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.

Comment 10

[Guy Schlosser]

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

Comment 11

[Jed Davis [:jld] ⟨⏰|UTC-8⟩ ⟦he/him⟧]

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.

Comment 12

[Jed Davis [:jld] ⟨⏰|UTC-8⟩ ⟦he/him⟧]

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

Comment 13

[Guy Schlosser]

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.

Comment 14

[Jed Davis [:jld] ⟨⏰|UTC-8⟩ ⟦he/him⟧]

Attachment: Bug 1884347 - Fix unprivileged userns detection to handle new a AppArmor feature.

Comment 15

[Ryan VanderMeulen [:RyanVM]]

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.

Comment 16

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/4a6d72cfbc42
Fix unprivileged userns detection to handle new a AppArmor feature. r=gcp

Comment 17

[Jed Davis [:jld] ⟨⏰|UTC-8⟩ ⟦he/him⟧]

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

Comment 18

[Cristian Tuns]

https://hg.mozilla.org/mozilla-central/rev/4a6d72cfbc42

Comment 19

[BugBot [:suhaib / :marco/ :calixte]]

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.

Comment 20

[Xavier]

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 !

Comment 22

[Gian-Carlo Pascutto [:gcp]]

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.

Comment 23

[Jed Davis [:jld] ⟨⏰|UTC-8⟩ ⟦he/him⟧]

Attachment: Bug 1884347 - Fix unprivileged userns detection to handle new a AppArmor feature.

Original Revision: https://phabricator.services.mozilla.com/D204326

Comment 24

[Phabricator Automation]

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)

Comment 25

[Jed Davis [:jld] ⟨⏰|UTC-8⟩ ⟦he/him⟧]

Attachment: Bug 1884347 - Fix unprivileged userns detection to handle new a AppArmor feature.

Original Revision: https://phabricator.services.mozilla.com/D204326

Comment 26

[Phabricator Automation]

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)

Comment 27

[Peter Magyari (Desktop QA)]

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.

Comment 28

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-release/rev/c32d64550d72

Comment 29

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-esr115/rev/1c004a56518c

Comment 30

[Peter Magyari (Desktop QA)]

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