On Tue 17-07-18 09:36:05, Steve Grubb wrote: > 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. OK. > > 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 These are file accesses I suppose. > 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.) Yes, but my point is you just cannot tell what a process is going to do with the file. E.g. if you run a script as ". my_script.sh", it will get executed for all practical purposes but there's no "open for execution" happening - the file is just read as any other and then interpretted. No way to discern this from "<my_script.sh" from kernel POV. And similar thing happens for dynamic libraries which is also executable code. And if you want to look specifically at "what's getting used for exec(2)?", then just trace exec(2) system call (either using audit or using syscall trace points) and you get all the details including file name. > > 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. 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... Honza -- Jan Kara <jack@xxxxxxxx> SUSE Labs, CR
