Issue applying seccomp filter to 3rd party binary

[Abhilash Raj]

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)

[Abhilash Raj]

Looks like i found my answer.

On Wed, Mar 18, 2020, at 5:11 PM, Abhilash Raj wrote:
> 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)
>

Turned out, I was reading this wrong. This was basically in response to -1 system call and hence seccomp didn't allow running the program without any filters either as <0 was assumed to be bad system call.

I saw that this has been fixed with 2.3.2 (RHEL has 2.3.1, damn!) and after compiling from source and adding API_TSKIP attribute to the Filter, I was able to get my program working!

> 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 libseccomp+...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/libseccomp/41be1a0c-9e10-46bc-a851-3878c994094b%40www.fastmail.com.