> This sounds like an LSM, possibly with a component which communicates
> with userspace, depending on how sophisticated "verify" needs to be.
Yes, the component *should* communicate with the userspace. The
sophistication of "verify" varies from user to user. The tool will
provide a few
> 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.
This sounds like an LSM, possibly with a component which communicates
with userspace, depending on how sophisticated "verify"
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
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*
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.
A big picture of the _main_ idea of interception would be: Application
called a syscall -> Intercept and
On Wed, 28 Jun 2017 17:48:15 -0300, Ben Mezger said:
> Can the kernel keep track of all the system calls that were called by an
> application/module in real-time?
> I know I can statically use strace, or even gdb, but I am looking for a
> solution in real time when the application/module is
