Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

'Intercepted forbidden syscall' when running check #39

Closed
jstpp opened this issue Nov 26, 2023 · 2 comments · May be fixed by #40
Closed

'Intercepted forbidden syscall' when running check #39

jstpp opened this issue Nov 26, 2023 · 2 comments · May be fixed by #40

Comments

@jstpp
Copy link

jstpp commented Nov 26, 2023

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
Copy link
Member

Wolf480pl commented Nov 26, 2023

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
Copy link
Author

jstpp commented Dec 7, 2023

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.

@jstpp jstpp closed this as completed Dec 7, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants