Keeping track of called syscalls in real-time

[valdis.kletnieks@vt.edu (valdis.kletnieks at vt.edu)]

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 486 bytes
Desc: not available
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20170628/44fa1b2d/attachment.bin