search

sio2project / sio2jail

A tool for supervising execution of programs submitted in algorithmic competitions
MIT License
29 stars 10 forks source link

'Intercepted forbidden syscall' when running check #39

Closed jstpp closed 7 months ago

jstpp commented 7 months ago

Hey! At the moment, I'm working on starting sio2jail on my server and I have some difficulties. When I used sudo make check command, I can see the following messages: LastTest.log

Rather, I'm wondering what intercepted forbidden syscall might be - before using sysctl -w kernel.perf_event_paranoid=-1, I observed another type of error - with perf events and forbidden access to them: System error occured: perf event open failed: Permission denied: error 13: Permission denied

Wolf480pl commented 7 months ago

perf event open failed: Permission denied: error 13: Permission denied

that means Linux kernel does now allow sio2jail to access the performance counters necessary to count how many instructions the program running inside sio2jail executes (which is how we determine "time" in case of contests such as the Polish Olympiad in Informatics).

sysctl -w kernel.perf_event_paranoid=-1

is a way of telling the Linux kernel that sio2jail (and every other program) should be allowed to use these counters.

This is unrelated to the forbidden syscall error you're getting later. This one means that the program running inside sio2jail made a system call that sio2jail does not allow.

Side note: I just noticed the readme is somewhat unintuitive, the "Running" section doesn't really say how to use sio2jail, and there's the "Running tests" section below which talks about make check - those are the tests we (should) use to check when developing sio2jail to check if it works correctly - they run some example programs under sio2jail to see if they behave as expected. If you actually want to know how to use sio2jail, there's a manpage here: https://github.com/sio2project/sio2jail/blob/master/doc/sio2jail.1.scd

I looked through your log and it looks like a few tests failed and they had different versions of the forbidden syscall error:

intercepted forbidden syscall statx(383) (1, 135063401, 6144, 2047, 4290067324, 4290067696)
intercepted forbidden syscall clone3(435) (140736485017904, 88, 5081936, 8, 22582829483584, 140736485018175)

clone3

clone3 and statx are the system calls that the example programs in the tests tried to call, and that sio2jail blocked.

clone3 is a system call used to create threads, it happened in test test_1_sec_program_threads_1, which runs a version of the 1-second-program that uses threads, and tells sio2jail to allow the program to create one thread.

Looking at the thread limiter code here https://github.com/sio2project/sio2jail/blob/master/src/limits/ThreadsLimitListener.cc#L30-L45

it looks like in that case sio2jail allows the use of clone system call, but not the clone3 one, introduced with Linux 5.3. You probably have a newer version of the compiler and/or the standard library, new enough that it tries to use the clone3 syscall. It'd be a good idea to add support of the clone3 syscall to sio2jail, in a similar way to how it handles the old clone.

However, this is only necessary for running multi-threaded programs under sio2jail. If you don't have plans to do that, you can safely ignore this error.

statx

This is a similar situation of a system call introduced in newer versions of linux, that newer versions of standard library started using, and sio2jail doesn't know about it.

Looks like this will be a problem for everyone using sio2jail on a new enough system, so support for this syscall needs to be added to sio2jail.

Similar system calls are handled here: https://github.com/sio2project/sio2jail/blob/master/src/seccomp/policy/DefaultPolicy.cc#L150-L180

There are two lists. The first one has the allowed syscalls, like stat, stat64, etc. In the second list are syscalls we tell Linux to pretend it doesn't know them: statfs, fstatfs, etc. - we make those syscalls return ENOSYS, which makes the standard library think that it's running on an old Linux system and it tries to continue without using these syscalls.

Returning ENOSYS is the safe way - it won't give the program inside sio2jail any new opportunities to try cheating or escaping.

Looking at the manpage of statx as well as /usr/include/linux/stat.h, it seems like the only new fields are the mount id and the direct IO alignment information. I don't know how useful those would be to an attacker, but the comments say there's room for further expansion in that struct, so I would rather not add statx to allowed syscalls unless we have to.

tl;dr

statx needs to be added soon, we should try ENOSYS first, only whitelist it if that causes problems clone3 needs to be added eventually, but it's only really needed if we care about threads Pull requests welcome.

jstpp commented 7 months ago

Thanks for help, and really detailed anwser! Generally, I used the fixes from the pull request and it fixed majority of 'errors' in my case.