Make filtering possible in the module side

[alexandernst]

Filtering data in the module instead of in the client will be faster (as no data will be sent anywhere, copied, pushed, etc...).

Probably the best way is to create some kind of macro and a sysctl interface for each hijacked syscall. Example: sysctl procmon.read=1 or sysctl procmon.write32=0

[milabs]

Do you plan to filter only by the syscall name or may be by args?

[alexandernst]

@milabs The best thing would be to comply with #3

[milabs]

@alexandernst Did you look at audit filtering implementation?

[alexandernst]

@milabs Nope, haven't had time yet :(
But I should look at it before doing anything related with this bug. (Anyways, my TODO list is full of queued stuff, implement the udis86 search, clean the netlink mess or maybe even replace it with something from http://stackoverflow.com/posts/comments/28484676?noredirect=1 ...)

[dandare100]

I initially wanted to place a configurable filter on the module, but I was worried that there might be multiple clients (one day), each requiring their own filter. So I thought keeping the "source" of events firing all events would be the best option (for me) for now.

Nice project! Thanks

[alexandernst]

I think there's no need for multiple clients. Procmon is too complex per-se for having multiple clients support. +I can't imagine a scenario where two different users would want to debug the same kernel on the same machine at the same time :/

Going further on that, I was thinking about this and maybe there could be some kind of macros magic that will create what I said in my first comment. That way we could disable everything from all unwanted syscalls and don't waste CPU cycles even sending them to the client.

And then, the remaining syscalls can be filtered on the client side (if pid is this or that, if the name starts with this, if the path ends with that, etc...)

[alexandernst]

Further more, multiple clients aren't possible with the current implementation as NetLink sends data to a single PID.
Broadcasting was implemented just in recent versions and requires root in userland, so that is a double no-no.

I'm thinking in switching to mmap (#21) but IIRC even then multiple clients won't work, so...

[dandare100]

Cool. Understood.Agreed :-)

[milabs]

Just an idea. It's possible to catch all the information in the userspace daemon with netlink, mmap or any other method. Next, this daemon listens for incoming connects from peoples that want's to see what happened on the system. So, this daemon will be a relay for others. The main problem is to filter out daemon activity...

[alexandernst]

That indeed is a good idea!

Each client (aka viewer) could filter by itself, so this way the daemon would just need to listen from kernel and send to each viewer that requests it.

There is one cons on that thou, If we do multiple clients, we won't be able to filter anything at all at the module level as perhaps viewer A would request every syscall, while viewer B would request just X, Y and Z syscalls.

I'm not convinced yet if multi-viewer should actually exist so I'll think about it. If anyone comes with a good idea how to waste the less possible cycles while having multi-viewer support, I'll do it :)

[alexandernst]

Closing this. I'll create a question tag/issue about a multi-viewer :)