| Summary: | After starting a plasma5 session, ~/.config/gtk-3.0 is altered and causes firefox to emit seccomp sandbox violation errors (and tab crashes with Nightly) [glib2.0 regression] | ||
|---|---|---|---|
| Product: | Mageia | Reporter: | Shlomi Fish <shlomif> |
| Component: | RPM Packages | Assignee: | Base system maintainers <basesystem> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | Normal | CC: | basesystem, ghibomgx, gnome, kde, ngompa13, pterjan, rverschelde, thierry.vignaud |
| Version: | Cauldron | Keywords: | UPSTREAM |
| Target Milestone: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| URL: | https://shlom.in/ | ||
| See Also: | https://gitlab.gnome.org/GNOME/glib/-/issues/2198 | ||
| Whiteboard: | |||
| Source RPM: | glib2.0-2.65.2-1.mga8 | CVE: | |
| Status comment: | |||
|
Description
Shlomi Fish
2020-09-01 10:53:48 CEST
According to pterjan:
> This is most likely due to glibc update, probably seccomp needs to be
> updated for it
I can reproduce the seccomp errors, and they lead to systematic crashing on tabs on Firefox Nightly (and Chromium).Assignee:
bugsquad =>
kde For the reference, we seem to have the latest libseccomp including a backport of a patch fixing a serious issue (which Neal was involved in for Fedora): https://github.com/seccomp/libseccomp/issues/273 I'll see if packaging libssecomp 2.4.4 locally (i.e. a downgrade to the previous stable branch) alleviates this new issue. CC:
(none) =>
ngompa13 (In reply to Rémi Verschelde from comment #2) > > I'll see if packaging libssecomp 2.4.4 locally (i.e. a downgrade to the > previous stable branch) alleviates this new issue. It does not, I downgraded to libseccomp 2.4.3 from the earlier SVN revision of our package, and I still get the same issue. Firefox tab crash backtrace (I installed debuginfo for glib2.0 and gio2.0 but it doesn't help): ``` Sandbox: Sandbox: unsupported flags 2048 in fstatat(-100, "/home/akien/.config/gtk-3.0/colors.css", 0x7F94F9903960, 2304) unsupported flags 2048 in fstatat(-100, "/home/akien/.config/gtk-3.0/colors.css", 0x7F95007FD960, 2304) Sandbox: seccomp sandbox violation: pid 59290, tid 59297, syscall 262, args 4294967196 140277938373680 140277935233376 2304 2304 1. Killing process. Sandbox: seccomp sandbox violation: pid 59290, tid 61591, syscall 262, args 4294967196 140277936453376 140277818866016 2304 2304 1. Killing process. Sandbox: crash reporter is disabled (or failed); trying stack trace: Sandbox: frame #01: __fxstatat64[/lib64/libc.so.6 +0xe739b] Sandbox: frame #02: ???[/lib64/libc.so.6 +0xe6fcc] Sandbox: frame #03: ???[/lib64/libgio-2.0.so.0 +0x1316da] Sandbox: frame #04: ???[/lib64/libgio-2.0.so.0 +0x12d1a7] Sandbox: frame #05: ???[/lib64/libgio-2.0.so.0 +0x600cc] Sandbox: frame #06: ???[/lib64/libgio-2.0.so.0 +0xaf0ee] Sandbox: frame #07: ???[/lib64/libglib-2.0.so.0 +0x792b4] Sandbox: frame #08: ???[/lib64/libglib-2.0.so.0 +0x789ee] Sandbox: frame #09: ???[/lib64/libpthread.so.0 +0x8df0] Sandbox: frame #10: clone[/lib64/libc.so.6 +0xf622f] Sandbox: frame #11: ??? (???:???) Sandbox: end of stack. ``` I would think the problem is more the sandboxes not reacting nicely when they get rejected due to that syscall having unexpected parameter, and the list of parameters accepted by seccomp for those apps should be updated. The reason this happens is likely a change in kernel (which would advertise a feature causing the apps to start using the parameter) or in glibc which would start using that syscall differently, and only glibc was upgraded recently. It could also be another library directly issuing the syscalls, or passing a flag that then get passed through by glibc. It is complaining about the 2048 bit which seems to be AT_STATX_DONT_SYNC so something started setting that flag or maybe started using fstatat altogether. CC:
(none) =>
pterjan It would be great to get a stacktrace wirh gio debuginfo, the change may be in gio. It seems glib 2.65.2 added some statx support. Also, as the problem happens when it looks at ~/.config/gtk-3.0/colors.css created by kde and used from an @include in ~/.config/gtk-3.0/gtk.css, commenting that include should workaround the problem at the cost of gtk apps not following kde colours. So it seems firefox only allows AT_SYMLINK_NOFOLLOW: https://hg.mozilla.org/mozilla-central/file/tip/security/sandbox/linux/SandboxFilter.cpp#l257 And it gets upset when gtk passes more flags... (In reply to Pascal Terjan from comment #5) > It would be great to get a stacktrace wirh gio debuginfo, the change may be > in gio. It seems glib 2.65.2 added some statx support. I installed glib2.0 and gio2.0 debuginfo, but Firefox's crash handler doesn't seem to be able to pick them up. I even tried https://developer.mozilla.org/en-US/docs/Mozilla/Using_the_Mozilla_symbol_server but that doesn't improve the stack trace. (In reply to Pascal Terjan from comment #7) > So it seems firefox only allows AT_SYMLINK_NOFOLLOW: > > https://hg.mozilla.org/mozilla-central/file/tip/security/sandbox/linux/ > SandboxFilter.cpp#l257 > > And it gets upset when gtk passes more flags... I guess we should report this to https://gitlab.gnome.org/GNOME/glib and/or https://bugzilla.mozilla.org? BTW, are others able to reproduce the issue too? I also get it on a second laptop running the same setup (Mageia 8 + Plasma + Firefox Nightly). Latest glibc patch IIRC was prior to this plasma change, and the only change regarding syscall was this: http://svnweb.mageia.org/packages/cauldron/glibc/current/SOURCES/0250-nptl-Zero-extend-arguments-to-SETXID-syscalls-BZ-262.patch?revision=1611995&view=markup which doesn't seem advertising a new kernel feature. Can you try downgrade either glibc (or other components) and/or boot with kernel 5.7 (if you add belnet.be to the mirror list it should have all the old versions packages, so you can downgrade packages easily by hand) to see if that would help? Speaking of syscall advertising of new features of kernel 5.8, there are two new patches in master trunk (which is for glibc 2.32/33 not 2.31): https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=1cfb4715288845ebc55ad664421b48b32de9599c and https://sourceware.org/git/?p=glibc.git;a=commit;h=42a00a0fb4c69d940ac5f6b08a57e045e14f22f7 AFAIK our glibc 2.31 version has all the kernel features up to 5.4 (see for instance file sysdeps/unix/sysv/linux/tst-mman-consts.py or scripts/build-many-glibcs.py). CC:
(none) =>
ghibomgx Yes it seems to be a problem between firefox being very restrictive with allowed flags (comment #7) and glib now using statx.
Rémi Verschelde
2020-09-02 13:34:18 CEST
Summary:
After starting a plasma5 session, ~/.config/gtk-3.0 is altered and causes firefox to emit many warnings on the terminal =>
After starting a plasma5 session, ~/.config/gtk-3.0 is altered and causes firefox to emit seccomp sandbox violation errors (and tab crashes with Nightly) I built 64-bit and 32-bit glib2.0-2.65.0-2.mga8 with mock (packages SVN r1609965) and downgraded all installed glib/gio packages, and I can confirm that it seems to solve the issue (after restoring a "broken" ~/.config/gtk-3.0 and restarting Firefox Nightly). Then re-upgrading to glib2.0-2.65.2-1.mga8 triggers the issue anew after restarting Firefox Nightly. Source RPM:
plasma-workspace-5.19.4-2.mga8.src.rpm =>
glib2.0-2.65.2-1.mga8 I filed a bug report upstream: https://gitlab.gnome.org/GNOME/glib/-/issues/2198 Assignee:
kde =>
basesystem Given that the upstream bug report was closed as "not our responsibility", and it's even less ours, I suggest that we revert glib to the stable branch (2.64.5). We'll have to wait for glib, Mozilla and Google to work together on how to update the sandboxing situation before we can consider shipping 2.65.2 or later. Since we narrowed the problem to glib2.0, waiting for some move on chromium/firefox, which was the latest glib2.0 working? 2.65.0 works? As an alternative to entire downgrading to 2.64.5, we can temporarely just revert the statx change in glib2.0 to its previous state and go on. This one seems the latest change involving statx: https://gitlab.gnome.org/GNOME/glib/-/commit/6fc143bba81a02cac0ca6bc47e8249b65ffc0ad9) we can try to see if reverting that patch fixes the problem (though probably would remain prone to this: https://gitlab.gnome.org/GNOME/glib/-/issues/2189, but I guess glib 2.64.x would be too). Well, yes 2.65.0 you said it was working. (In reply to Giuseppe Ghibò from comment #15) > Well, yes 2.65.0 you said it was working. Personally, given how upstream handles report about issues created by the dev releases, I'd prefer that we go back to stable (2.64.5). Looking at reverting that patch, I noticed that we use that patch on 2.65.2 on purpose for fixing glib bug #2189, see: http://svnweb.mageia.org/packages/cauldron/glib2.0/current/SOURCES/0001-gio- Allow-no-atime-from-statx.patch?view=log Maybe just removing that patch could help (probably 2.64.5 is affected too), waiting for chrome/firefox reaction on final glib2.0 release. We could try. Fixed in glib2.0-2.65.2-2.mga8 by commenting out `HAVE_STATX` in `meson.build` as suggested by Christiaan Welwaart on the dev ML. http://svnweb.mageia.org/packages/cauldron/glib2.0/current/SPECS/glib2.0.spec?r1=1619697&r2=1621246&pathrev=1621247 Resolution:
(none) =>
FIXED Nice catch! Though now, it would be nice if upstream could update the allowlist to include statx (In reply to Thierry Vignaud from comment #19) > Though now, it would be nice if upstream could update the allowlist to > include statx Yeah definitely. Someone(TM) needs to file bug reports with Firefox and Chromium to let them know of the sandboxing violation with glib 2.65.2+. Given that upstream GLib doesn't seem to see it as their responsibility, I guess we'll have to be the good open source citizens and do it for them... |