mirror of
https://github.com/netblue30/firejail.git
synced 2026-05-15 14:16:14 -06:00
[GH-ISSUE #4686] Seccomp is blocking Steam from launching a child container #2747
Labels
No labels
LTS merge
LTS merge
bug
bug
converted-to-discussion
doc-todo
documentation
duplicate
enhancement
file-transfer
firecfg
firejail-in-firejail
firetools
graphics
help wanted
information_old
installation
invalid
modif
moved
needinfo
networking
notabug
notourbug
old-version
overlayfs
packaging
profile-request
pull-request
question
question_old
removal
runtime-permissions
sandbox-ipc
security
stale
wiki
wiki
wontfix
wordpress
workaround
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/firejail#2747
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @swimik on GitHub (Nov 14, 2021).
Original GitHub issue: https://github.com/netblue30/firejail/issues/4686
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 seccompin 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.
@SkewedZeppelin commented on GitHub (Nov 14, 2021):
https://github.com/netblue30/firejail/issues/4366
@swimik commented on GitHub (Nov 14, 2021):
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 --followand was able to see a bunch of syscalls but none seemed to be blocked. It kind of seems like the runningfirejail --seccomp-error-action=log /path/to/programruns similar toignore seccompthese 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.
@rusty-snake commented on GitHub (Nov 14, 2021):
How did you excluded/commented them?
There's an
arch=field in you syslog.@swimik commented on GitHub (Nov 14, 2021):
This is how I commented out the syscalls after I looked them up using firejail
these are the unique syscalls logged from journalctl
For syslog there is nothing being logged when this error occurs that is related to steam or firejail
@swimik commented on GitHub (Nov 21, 2021):
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?
@remyabel2 commented on GitHub (Dec 30, 2021):
Disregard, I commented on the wrong issue.