[GH-ISSUE #3] seccomp always blocks syscall=45 (recvfrom) #3

New issue

Closed

opened 2026-05-05 04:42:03 -06:00 by gitea-mirror · 3 comments

gitea-mirror commented

2026-05-05 04:42:03 -06:00

Owner

Originally created by @boltronics on GitHub (Aug 9, 2015).
Original GitHub issue: https://github.com/netblue30/firejail/issues/3

I tried running Steam in firejail using the seccomp option in the profile, which resulted in
Steam failing to launch and syslog reporting syscall=45 (recvfrom) has been blocked. Strange, since that wasn't mentioned in the man page as being blacklisted.

Then I tried replacing seccomp with the option
seccomp.drop mount,umount2,ptrace,kexec_load,open_by_handle_at,init_module,finit_module,delete_module,iopl,ioperm,swapon,swapoff,mknode,syslog,process_vm_readv,process_vm_writev,sysfs,_sysctl,adjtimex,clock_adjtime,lookup_dcookie,perf_event_open,fanotify_init,kcmp
where all syscalls are taken from the list in the firejail(1) man page (under --seccomp section) as being the default blacklist, but I still get the same error.

I even went so far as to comment out every other line in my profile for Steam (including "include" lines) and I still run into the same issue.

Wine is also affected by this (even just running wine --version will result in the same failure).

Originally created by @boltronics on GitHub (Aug 9, 2015). Original GitHub issue: https://github.com/netblue30/firejail/issues/3 I tried running Steam in firejail using the seccomp option in the profile, which resulted in Steam failing to launch and syslog reporting syscall=45 (recvfrom) has been blocked. Strange, since that wasn't mentioned in the man page as being blacklisted. Then I tried replacing `seccomp` with the option `seccomp.drop mount,umount2,ptrace,kexec_load,open_by_handle_at,init_module,finit_module,delete_module,iopl,ioperm,swapon,swapoff,mknode,syslog,process_vm_readv,process_vm_writev,sysfs,_sysctl,adjtimex,clock_adjtime,lookup_dcookie,perf_event_open,fanotify_init,kcmp` where all syscalls are taken from the list in the firejail(1) man page (under --seccomp section) as being the default blacklist, but I still get the same error. I even went so far as to comment out every other line in my profile for Steam (including "include" lines) and I still run into the same issue. Wine is also affected by this (even just running `wine --version` will result in the same failure).

gitea-mirror

2026-05-05 04:42:03 -06:00

closed this issue
added the
bug
label

gitea-mirror commented

2026-05-05 04:42:11 -06:00

Author

Owner

@netblue30 commented on GitHub (Aug 10, 2015):

I better fix this asap, thanks!

@netblue30 commented on GitHub (Aug 10, 2015): I better fix this asap, thanks!

gitea-mirror commented

2026-05-05 04:42:17 -06:00

Author

Owner

@netblue30 commented on GitHub (Aug 15, 2015):

wine is a 32bit executable - at least on my Debian system. The seccomp filter is architecture specific, set at compile time - 64bit for most users. It turns out syscall numbers don't match in 32bit and 64bit architectures. For example, syscall 311 is a harmless sys_set_robust_list on 32bit and a troublesome process_vm_writev on 64bit (disabled by the default filter on 64bit architectures).

"firejail --seccomp wine --version" fails the architecture validation at the start of default filter, printing a false recvfrom syscall. If I remove the architecture validation at the start of the filter, I immediately get syscall 311 failing. This will never work without heavy duty lifting in Linux kernel.

The workaround is not to use seccomp in this case. Instead, try --caps.drop=all. I'll close the bug for now.

@netblue30 commented on GitHub (Aug 15, 2015): wine is a 32bit executable - at least on my Debian system. The seccomp filter is architecture specific, set at compile time - 64bit for most users. It turns out syscall numbers don't match in 32bit and 64bit architectures. For example, syscall 311 is a harmless sys_set_robust_list on 32bit and a troublesome process_vm_writev on 64bit (disabled by the default filter on 64bit architectures). "firejail --seccomp wine --version" fails the architecture validation at the start of default filter, printing a false recvfrom syscall. If I remove the architecture validation at the start of the filter, I immediately get syscall 311 failing. This will never work without heavy duty lifting in Linux kernel. The workaround is not to use seccomp in this case. Instead, try --caps.drop=all. I'll close the bug for now.

gitea-mirror commented

2026-05-05 04:42:21 -06:00

Author

Owner

@boltronics commented on GitHub (Aug 15, 2015):

No worries. Thanks for looking into it.

@boltronics commented on GitHub (Aug 15, 2015): No worries. Thanks for looking into it.

gitea-mirror referenced this issue

2026-05-05 05:06:26 -06:00

[GH-ISSUE #175] using links in sandboxed firefox #121

gitea-mirror referenced this issue

2026-05-05 08:08:47 -06:00