On Tuesday, July 17, 2018 8:44:23 AM EDT Jan Kara wrote: > On Mon 16-07-18 16:29:42, Steve Grubb wrote: > > Hello, > > > > On Monday, July 16, 2018 11:26:53 AM EDT Jan Kara wrote: > > > On Mon 16-07-18 18:50:11, Matthew Bobrowski wrote: > > > > Currently, the fanotify API does not provide a means for user space > > > > programs to register and receive events specifically when a file has > > > > been > > > > opened with the intent to be executed. Two new event flags FAN_EXEC > > > > and > > > > FAN_EXEC_PERM have been introduced to the fanotify API along with > > > > updates > > > > to the generic filesystem notification hooks fsnotify_open and > > > > fsnotify_perm in order to support this capability. > > > > > > > > Signed-off-by: Matthew Bobrowski <mbobrowski@xxxxxxxxxxxxxx> > > > > > > I miss one important part in this changelog: Why do you need this > > > feature? > > > Monitoring for read would be enough after all... > > > > There are several reasons that I can think of. There are lots of file > > accesses. It is possible to guess which one is the beginning of an > > execve, but you really don't know. Apps can be started in so many ways. > > They can be run from the runtime linker, they have LD_PRELOAD, they can > > have an unexpected interpreter, they can be statically linked, they can > > be a script which may present a new pattern of file accesses. With all > > the variations in how programs can start up, it would be nice to have one > > anchor that unambiguously says we are overlaying this pid with a whole > > new app and forget everything you knew about the pid. And the access > > pattern can be accurately watched because we always have a marker to > > start the sequence. > > I don't quite buy your "marker that pid is starting from scratch" argument. > Firstly, you'd have to place fanotify watches on all executables in your > system to even have a chance to tell that, True and we do. > secondly, the process does not quite start a new - it still inherits some > stuff from the old process like open file descriptors... True. But that is not exactly relevant to the issues we're looking at. > So I understand exec might be interesting for audit purposes but then you > should watch it using audit and not fanotify which is for handling / > mediating filesystem accesses. This is not being used for the audit system. But let me illustrate the issue that I'm looking at. I have the following sequence of events: pid=13247 exe=/usr/bin/bash file=/home/sgrubb/test/static/test pid=13250 exe=/usr/bin/bash file=/usr/bin/sed pid=13250 exe=/usr/bin/bash file=/usr/lib64/ld-2.27.so pid=13250 exe=/usr/bin/sed file=/etc/ld.so.cache 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 pid=13259 exe=/usr/bin/bash file=/home/sgrubb/test/static/wc pid=13259 exe=/usr/bin/bash file=/home/sgrubb/test/static/test2 There is a clear pattern for sed. But what was bash doing to test? There is no pattern. Was it an execution or echo "blah" > test? How can you tell? Then what happened to test2? (The first was execution of static app, last was piping the program to wc -c. They pretty much leave the same footprint but what is happening is very different.) > And when you are looking at filesystem accesses, then there's no real > difference between exec and read which is exactly why I'm not sure why the > new feature is being added. Its about intention to do something different with the data after the read. That intention is important and just out of reach. But I otherwise agree that read and execute do pretty much the same thing. -Steve
