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@xxxxxx 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
_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@xxxxxxxxxxxxxxxxx
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
