Constant bubblewrap crashes with the new glycin

[Hasshu]

Your system information

• Steam client version (build number or date): 1769025840 (Wed, Jan 21 20:12 UTC -08:00)
• Distribution (e.g. Ubuntu): Fedora Linux 43 (Workstation Edition)
• Opted into Steam client beta?: No
• Have you checked for system updates?: Yes
• Steam Logs: (See below.)
• GPU: AMD

Please describe your issue in as much detail as possible:

Locking the screen on GNOME 49 while Steam is running is guaranteed to cause two bubblewrap crashes in a row. Apparently, it's related to a certain glycin update.

Of note is the following journalctl entry produced by Steam:

WARNING: Glycin running without sandbox.

See also:

• Frequent bubblewrap crashes on Fedora Linux 43 containers/bubblewrap#727
• Frequent bubblewrap crashes with the new glycin (#263) · Issue · GNOME/glycin
• Response from a glycin developer:

I don’t know why this is triggered by locking the screen, but it makes sense that this happens with Steam, if it is running in pressure-vessel. In this case, the mentioned bwrap call, trying to launch /usr/bin/true as a test, fails. This call is used by glycin to test if sandboxing image loading is possible. It should only happen once for a process since the result is cached.

Sadly, in the case of Steam/pressure-vessel, it seems impossible to find out if sandboxing is possible without getting killed by SIGSYS. That is something that they probably explicitly specified to happen in their seccomp rules. I’m not aware of any other sandbox that does it this way, and afaik there is no security related reason to do it this way.

Steps for reproducing this issue:

1. Launch Steam (RPM) on Fedora Linux 43 with GNOME 49
2. Lock the screen
3. Observe gnome-abrt having a bubblewrap seizure

[smcv]

Sadly, in the case of Steam/pressure-vessel, it seems impossible to find out if sandboxing is possible without getting killed by SIGSYS. That is something that they probably explicitly specified to happen in their seccomp rules

pressure-vessel definitely doesn't set any seccomp rules on itself or its child processes: it is a container, but not a sandbox (not a security boundary).

Maybe some part of Steam does? Only Valve would be able to confirm whether it does. (Note to any Valve developers who might look at this: references to SCMP_ACT_TRAP or SCMP_ACT_KILL would be the place to start looking.)

If pressure-vessel is working as intended, then the OS's gdk-pixbuf shouldn't usually be getting loaded by any process that runs inside a pressure-vessel container: its purpose is to swap out /usr for one with long-term-stable application-layer libraries that don't change when the OS changes.

It is possible that gdk-pixbuf is somehow getting pulled into the container as a dependency, if a graphics driver or Vulkan layer depends on it (which would be generally bad for the container's predictability). A Help → System Info report from Steam would indicate whether this is happening: if it is, the runtime → overrides → list section would list overrides/lib/x86_64-linux-gnu/libgdk-pixbuf-2.0.so.0 or similar.

Processes being killed by SIGSYS usually mean seccomp, but it's also possible that there is some other component (SELinux?) that is terminating processes with SIGSYS if they do something that it doesn't like.

[smcv]

I can reproduce a similar crash on Debian unstable, which has the new gdk-pixbuf/glycin versions, but not SELinux, so that rules out SELinux as a cause.

The crashing bwrap process seems to be a direct child of the main steam process (the executable is ubuntu12_32/steam), so, nothing to do with pressure-vessel (and it is the system bwrap that is crashing, not Steam's srt-bwrap). Probably the main steam process is loading gdk-pixbuf via GTK or some related library, and loading icons or other resources: previously this was done in-process, but with the new gdk-pixbuf it's done via glycin and a loader subprocess.

I think part of the problem might be that Steam is running with a non-trivial LD_LIBRARY_PATH (the old LD_LIBRARY_PATH Steam Runtime, not the newer container) and that LD_LIBRARY_PATH will be inherited by the bwrap subprocess, causing it to load libraries that are not necessarily the same ones it would be loading when run as an ordinary system process.

One possible explanation is that if Steam applies seccomp rules to itself, then the bwrap subprocess run by glycin might be doing something that those rules don't allow. I can't see any obvious uses of seccomp in the Steam binaries in ubuntu12_32/ though: the only mentions of seccomp seem to be in command-line options to make the Chromium-derived steamwebhelper not use seccomp.

Another possible explanation is that something in the process state inherited by bwrap from steam - either the LD_LIBRARY_PATH, or some other aspect of inheritable state - is making bwrap behave differently, so that the seccomp rules set up by glycin, which would normally allow bwrap to work, no longer do.

It is a child of steam that is crashing, not a child of steamwebhelper, so steamwebhelper can be ignored here.

[smcv]

To investigate this, it can be useful to move /usr/bin/bwrap to /usr/bin/bwrap.real, and replace /usr/bin/bwrap with an executable script something like this:

#!/bin/bash
set -eu
pid="$$"
(
printf 'pid %s,' "$pid"
printf ' %q' "$@"
printf '\n'
) | logger -t bwrap-wrapper
pstree -ps $$ | logger -t bwrap-wrapper
env | logger -t bwrap-wrapper
exec /usr/bin/bwrap.real "$@"

The process ID that crashes will be a few increments more than the one that is logged to the system log, but with that extra information they can be correlated a bit more easily.