Bug 1884347 Comment 8 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

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][probe], 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][lp2056190] 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, 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.

[probe]: https://searchfox.org/mozilla-central/rev/b60cb73160843adb5a5a3ec8058e75a69b46acf7/security/sandbox/linux/SandboxInfo.cpp#137-138
[lp2056190]: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2056190
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][probe], 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][lp2056190] 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.

[probe]: https://searchfox.org/mozilla-central/rev/b60cb73160843adb5a5a3ec8058e75a69b46acf7/security/sandbox/linux/SandboxInfo.cpp#137-138
[lp2056190]: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2056190

Back to Bug 1884347 Comment 8