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.

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.

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.

I believe this is a consequence of Steam being a 32-bit process: https://gitlab.gnome.org/GNOME/glycin/-/issues/269

Having the same issue on fedora 44, gnome with wayland.