Hey All, I have a question related to libseccomp, which I thought this would be the best audience to ask to.
I am trying to sandbox a 3rd party binary by wrapping it in a simple python script which loads up a filter and execs the binary so it can inherit the filter. I am working with libseccomp v2.3.1 on Linux 3.10.0-862 (RHEL 7.5 Kernel). Kernels on RHEL7 are heavily patched so I am not sure about the source of this bug. And everything is old too. I created a simple filter with default action of ERRNO(13) and ALLOW specific system calls that I traced from `strace -f -c` run of the binary. However, that didn't really do the job and the applicaiton kept crashing with "Bad system call". A little bit of more searching led me to the fact that the message is emitted by shell when trying to run a system call that does not exist if the child process doesn't have an handler. I changed to filter to have default action of ALLOW and simply loaded it and ran the binary and it still kept failing with "Bad system call". The run of application without any seccomp filter doesn't fail with any such error. Looking more closely to the output of strace brought me to a syscall unknown to strace. syscall_18446744073709551615(0, 0x56240c95f118, 0, 0x7f3eb13922b0, 0xffff, 0) = -1 (errno 38) I am still trying to dig through to figure out what system call that is, but I have two questions about this? 1. How does seccomp handle unknown syscalls if there is a filter loaded with a default action of ALLOW? 2. Is this something folks have seen before and are there workarounds/fixes for this? Thanks very much in advance! -- thanks, Abhilash Raj (maxking) -- You received this message because you are subscribed to the Google Groups "libseccomp" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/libseccomp/41be1a0c-9e10-46bc-a851-3878c994094b%40www.fastmail.com.
