Keeping track of called syscalls in real-time

[Ben Mezger]

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 at 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