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

[Steve Grubb <sgrubb@redhat.com>]

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@mbobrowski.org>
> > > 
> > > 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