Re: fanotify as syscalls

Davide Libenzi
2009-09-22T14:52:11Z

On Tue, 22 Sep 2009, Jamie Lokier wrote:

> I don't mind at all if fanotify is replaced by a general purpose "take
> over the system call table" solution ...

That was not what I meant ;)
You'd register/unregister as syscall interceptor, receiving syscall number
and parameters, you'd be able to return status/error codes directly, and
you'd have the ability to eventually change the parameters. All this
should be pretty trivial code, and at the same time give full syscall
visibility to the modules.
The complexity would be left to the interceptors, as they already do it
today.

> But I can't help noticing that we _already_ have quite well placed
> hooks for intercepting system calls, called security_this and
> security_that (SELinux etc), ...

That has "some" limits WRT non-GPL modules and relative static linkage.

> However, being a little kinder, I suspect even the anti-malware
> vendors would rather not slow down everything with race-prone
> complicated tracking of everything every process does... which is why
> fanotify allows it's "interest set" to be reduced from everything to a
> subset of files, and it's results to be cached, and let the races be
> handled in the normal way by VFS.

They are already doing it today, since they are forced to literally find
and hack the syscall table.
They already have things like process whitelists, path whitelists, scan
caches, and all the whistles, in their code.
Of course, some of them might be interested in pushing given complexity
inside the kernel, since they won't have to maintain it.
Some other OTOH, might be interested in keeping a syscall-based access,
since they already have working code based on that abstraction.
The good part of this would be that all the userspace communication API,
whitelists, caches, etc... would be left to the module implementors, and
not pushed inside the kernel.
That, and the flexibility of being able to intercept all the userspace
entrances into the kernel.

- Davide