Let me clear things out.
As I said before - knowing this, what do you *do* with it? Statistics after the fact? Apply security rules before the fact? Something else? The answer depends *a lot* on what you're planning to *do* with the info.
There is no statistics involved. I am trying to intercept *some* system calls. The list of syscalls I should intercept will be set by the user in a form of a rule, however, if a specified syscall is meant for file I/O (i.e. fopen), the user would need to specify which files he would like the interception to take part on whenever fopen is called. A simple example of a user rule would be (in a nutshell): # syscall #intercept #file_arg #action #onuid #oncall fopen 1 /etc/shadow verify 12 0 Where #syscall specifies which syscall to intercept, #intercept is a bool whenever it should run or not, the #file_arg basically says "intercept fopen only when fopen is called on /etc/shadow", #action specifies the name of the procedure the tool would run when intercepting fopen, #onuid specifies the user uid to intercept (run this just on the user who has 12 as uid) and finally, #oncall is a bool telling the tool to intercept after the syscall has returned (1 for after the call, 0 for before). Whenever fopen("/etc/shadow", "r") is called, the tool would intercept it, run the verify() procedure, and return back to the syscall, allowing it to do it's job.
Yes, but the question is "what value of "I then receive" appropriate? Do you need it before the syscall is executed? After it is finished? Or "don't care at all as long as we eventually get a complete trail"?
That all depends on the config for *that* specific call. Using the previous examples, I would need the kernel to tell me right when fopen was called; int foo(...){ ... fopen(arg, "r"); <- need an alert from the kernel here } I am using the word "tool" here, but I am willing to get this builtin to the kernel when compiling it, so as a root user, it would be slightly more difficult to disable it without having to recompile everything (afaik).
Congrats - you just re-invented the LSM subsystem. Or possibly seccomp, depending on what it is you're trying to accomplish.
Note that LSM's have some restrictions on what they can and can't do, mostly because it's otherwise almost impossible to do any reasoning about the security and stability guarantees of a process/system otherwise.
I understand seccomp and LSM allows __some__ type of syscall interposition (where afaik seccomp blocks mostly all of them), but what I am willing to do here is not *reinvent* the wheel, I am willing to make things a bit more configurable, where a user has access to an API where he could write custom procedures to run on the interception side, without having to dig through the source. Many thanks On 06/28/2017 07:26 PM, valdis.kletnieks@vt.edu wrote:
On Wed, 28 Jun 2017 19:06:56 -0300, Ben Mezger said:
I'm actually formulating my thesis project. I am looking for a way to intercept system calls (those chosen by the users), where I can keep track of what syscall has been called and by who.
As I said before - knowing this, what do you *do* with it? Statistics after the fact? Apply security rules before the fact? Something else? The answer depends *a lot* on what you're planning to *do* with the info.
A big picture of the _main_ idea of interception would be: Application called a syscall -> Intercept and delay call -> do something before the call -> return back to the syscall.
"Do something before the syscall".
Congrats - you just re-invented the LSM subsystem. Or possibly seccomp, depending on what it is you're trying to accomplish.
Note that LSM's have some restrictions on what they can and can't do, mostly because it's otherwise almost impossible to do any reasoning about the security and stability guarantees of a process/system otherwise.
By real-time I mean as soon as an application called a syscall (i.e. fopen), I could then receive a reply from the kernel informing me X called fopen, where X could be a pid or whatever.
Yes, but the question is "what value of "I then receive" appropriate? Do you need it before the syscall is executed? After it is finished? Or "don't care at all as long as we eventually get a complete trail"?
Have you looked at the syscall audit facility?
I have not. Are you talking about auditctl?
That's part of the userspace utilities that interface to the audit system.
-- - seds ~> https://seds.nl