Question

I want to kill a child process if it does other system calls than read and write (and even filter these calls as well, but it’s a different story) but there some system calls done by default.

I have compiled an empty test child (exits instantly) program and I also have a parent process which forks, enables ptracing and executes the child program. Parent process uses PTRACE_SYSCALL and checks orig_eax every time. My test program reports that the child was stopped 49 times (which, I assume, means 48 / 2 + 1 system calls).

I wanted to know whether the system calls sequence is always the same (initialization) and/or it’s possible to know when I can start and when to stop kill-on-syscall in my parent?

Answer 1

I had a similar problem once (see my question on the topic). When a program starts, it executes a lot of system calls when initializing the application (such as loading shared libraries) before calling main(). What I did is to simply allow somewhat more system calls and use another means of security (such as chroot) to prevent the application from accessing undesired files.

A better option would be to somehow find the entry point of the main() function of the program (see this tutorial for writing debugging code) and disable system calls after that point. I don’t know if it’s possible to do in general case, but that’s the way I would start to search.

After finding the entry point, there is another way of restricting the program from making certain system calls. Instead of using PTRACE_SYSCALL to check each system call done by the program, inject a prctl(PR_SET_SECCOMP, ...) call to the program (using ptrace()) then just leave the program running.