Re: [PATCH] fanotify: introduce event flags FAN_EXEC and FAN_EXEC_PERM

[Steve Grubb <sgrubb@redhat.com>]

Hello Jan,

On Thursday, July 19, 2018 5:33:07 AM EDT Jan Kara wrote:
> Yes, and my point is the intention is sometimes communicated and sometimes
> not. And I don't want to add an API which is vaguely defined...

Maybe this is better illustrated with actual data. For an application 
whitelisting daemon to be usable, it has to cache information and look that 
up rather than make expensive syscalls in order to make a decision. Every 
syscall it makes is delaying system access.

So, how can we tell when its time to evict cached information and start over? 
We are given 2 pieces of information in a fanotify event. The fd and the pid. 
What can be done to find an execve is to stat("/proc/pid") and look at the 
inode create time. Suppose we have this event stream:

pid=13250 exe=/usr/bin/bash file=/usr/bin/sed  <- execve occurs here
pid=13250 exe=/usr/bin/bash file=/usr/lib64/ld-2.27.so
pid=13250 exe=/usr/bin/sed file=/etc/ld.so.cache  <- /proc/pid updated here
pid=13250 exe=/usr/bin/sed file=/usr/lib64/libacl.so.1.1.2253
pid=13250 exe=/usr/bin/sed file=/usr/lib64/libselinux.so.1
pid=13250 exe=/usr/bin/sed file=/usr/lib64/libc-2.27.so
pid=13250 exe=/usr/bin/sed file=/usr/lib64/libattr.so.1.1.2448
pid=13250 exe=/usr/bin/sed file=/usr/lib64/libpcre2-8.so.0.7.0
pid=13250 exe=/usr/bin/sed file=/usr/lib64/libdl-2.27.so
pid=13250 exe=/usr/bin/sed file=/usr/lib64/libpthread-2.27.so
pid=13250 exe=/usr/bin/sed file=/usr/lib/locale/locale-archive

In this example, we can determine that execve occurs, but we are 2 accesses 
late in knowing this. We can keep a ring buffer to have this history for 
pattern analysis but its not ideal. Contrast that with a statically linked 
program:

pid=13247 exe=/usr/bin/bash file=/home/sgrubb/static/test <- execeve here
..

We cannot tell that an execution occurs because by the time /proc/pid updates 
its creation time, execution has already happened and we don't see that 
executable again until it accesses a file and then we can notice its a new 
program. By then its too late.

I suppose we could use tracing as you suggested. But then we need to 
correlate the 2 independent event streams in addition possibly adding 
additional system overhead. And considering there is an event queue inside 
the daemon, finding the right fanotify event in the queue to add this 
metadata to will add complexity and may be prone to error due to racing. A 
simpler solution is to just tag the access as originating from execve and 
it's automatically correlated with file access and the cost is perhaps a 
couple if statements.

Hope this helps...

-Steve