Closed swimik closed 2 years ago
Sorry I saw that post when I was looking for similar issues but for some reason I thought it was a forum for flatpak not firejail. I wouldn't have duplicate posted especially since it was first reported a few days ago.
I had tried the trick with viewing journalctl --grep=SECCOMP --follow
and was able to see a bunch of syscalls but none seemed to be blocked. It kind of seems like the running firejail --seccomp-error-action=log /path/to/program
runs similar to ignore seccomp
these are the syscalls that came up and their translation 64 bit / 32 bit 303 name_to_handle_at / 303 linkat 166 umount / vm86 165 mount / getresuid 155 pivot_root / sched_getparam
303 was for winedevice.exe, the rest were for SteamLinuxRuntime_soldier. Excluding each of these out for seccomp and seccomp.32 did not change the issue though, and nothing changed from the journalctl output with these commented out.
Excluding each of these out for seccomp and seccomp.32 did not change the issue though, and nothing changed from the journalctl output with these commented out.
How did you excluded/commented them?
64 bit / 32 bit
There's an arch=
field in you syslog.
It kind of seems like the running firejail --seccomp-error-action=log /path/to/program runs similar to ignore seccomp
SECCOMP_RET_KILL_THREAD (or SECCOMP_RET_KILL) This value results in immediate termination of the thread that made the system call. The system call is not exe‐cuted. Other threads in the same thread group will continue to execute. SECCOMP_RET_ERRNO This value results in the SECCOMP_RET_DATA portion of the filter's return value being passed to user space as the errno value without executing the system call. SECCOMP_RET_LOG (since Linux 4.14) This value results in the system call being executed after the filter return action is logged.
This is how I commented out the syscalls after I looked them up using firejail
seccomp !ptrace,!kcmp,!name_to_handle_at,!umount,!mount,!pivot_root
secomp.32 !getresuid32,!vm86,!linkat,!sched_getparam
these are the unique syscalls logged from journalctl
Nov 14 11:54:13 audit[192973]: SECCOMP auid=1000 uid=1000 gid=1000 ses=3 subj==unconfined pid=192973 comm="pv-bwrap" exe="/home//.local/share/Steam/steamapps/common/SteamLinuxRuntime_soldier/pressure-vessel/bin/pv-bwrap" sig=0 arch=c000003e syscall=165 compat=0 ip=0x7f3f94a906ba code=0x7ffc0000
Nov 14 11:54:13 audit[192973]: SECCOMP auid=1000 uid=1000 gid=1000 ses=3 subj==unconfined pid=192973 comm="pv-bwrap" exe="/home//.local/share/Steam/steamapps/common/SteamLinuxRuntime_soldier/pressure-vessel/bin/pv-bwrap" sig=0 arch=c000003e syscall=155 compat=0 ip=0x7f3f94a8a5e9 code=0x7ffc0000
Nov 14 11:54:13 audit[192973]: SECCOMP auid=1000 uid=1000 gid=1000 ses=3 subj==unconfined pid=192973 comm="pv-bwrap" exe="/home//.local/share/Steam/steamapps/common/SteamLinuxRuntime_soldier/pressure-vessel/bin/pv-bwrap" sig=0 arch=c000003e syscall=166 compat=0 ip=0x7f3f94a8fa97 code=0x7ffc0000
Nov 14 11:54:14 **** audit[193021]: SECCOMP auid=1000 uid=1000 gid=1000 ses=3 subj==unconfined pid=193021 comm="winedevice.exe" exe=2F686F6D652F636F75726965722F2E6C6F63616C2F73686172652F537465616D2F737465616D617070732F636F6D6D6F6E2F50726F746F6E202D204578706572696D656E74616C2F66696C65732F62696E2F77696E6536342D7072656C6F61646572 sig=0 arch=c000003e syscall=303 compat=0 ip=0x7f2aad6bb8ca code=0x7ffc0000
For syslog there is nothing being logged when this error occurs that is related to steam or firejail
So versions of proton below 5.13 will at least load the game launcher(with just the standard seccomp !pstate, !kcmp exclusions), it wont run the actual game but I did not look into why yet.
I remember reading that steam started launching programs in their own containers in recent versions of proton. Perhaps I can review Protons code later in the week and see what it is trying to do.
If what I think is happening is true, that firejail is launching a chroot jail with least privilege (1000 i think?) and steam is also trying to launch a jail with least privilege then if I understand the process correctly steam wont be able to do this because it is already least privilege? If that is the case can I set the privilege level in the steam firejail to 999 or something to give steam one less privilege tier to create a process?
Disregard, I commented on the wrong issue.
System is running on debian testing(currently bookworm). Thanks all for any help here.
I am trying to run some games with steam and proton. I am running into a seccomp problem that is producing no logs in kern.log or syslog for apparmor, firejail, seccomp, or anything really of note. I believe what is happening is SteamRuntimeLinux is trying to launch its own container and this is being blocked by firejail. Perhaps because it is launching in a containerized processes that is why it does not appear in the main system logs.
This is the error that is coming up when a game tries to launch. Nothing extra shows up when I run firejail --debug steam either. Although I wont attest I didnt miss something with all the extra debug output noise.
setting
ignore seccomp
in the profile works to fix this problem but that kind of seems pointless for the sake of the sandbox. I tried whitelisting the folder but that also had no effect.Here is the strace output I am kind of hoping someone could chime in on what to exclude here because doing this line by line would take quite a while. Currently my steam.local profile setup is seccomp !kcmp,!ptrace and seccomp32 !kcmp,!ptrace. kcmp had to be excluded for a gpu related comparability issue.