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:
> > 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"

That is true. But a shell script eventually causes a real execution of 
something. The main problem is when it comes to statically linked programs. 
You get one view of the program and its gone. Unlike dynamically linked 
programs where there is a chain of things that happen. But going back to the 
script example, the binary interpretting the script has not changed so we can 
continue to maintain information about that pid.


> 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.

Any special handling of shared objects is not needed. The important thing is 
twofold. The first knowing that any information about that pid is now being 
overlaid and therefore we have to start over in determining trust. But also 
if the execution is a statically linked program, we absolutely need to know 
the intent. It is impossible to tell a benign read or write from an actual 
execution given what we know via the fanotify interface.
 
> 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.

Wouldn't that hurt overall system performance?

> > > 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...

To me, its pretty crisp. For everything except statically linked programs, 
there are patterns of access that tell you what is going on. But sometimes 
you need that marker to know this is the beginning of a sequence and start 
over and build up new information. And in the case of statically linked 
program, there is no pattern of access. It's one shot and its over. It's very 
important to identify the intent for this item. 

And I'd say, impossible to make decisions that allow certain system activity 
like creation of a file or packaging of a file vs stopping the execution of 
something unknown. More information is needed so that the system is tolerant 
of user activity and not a PITA because it has to be super paranoid. For 
example, system update. All these files are unknown but they are being 
written and not executed. This activity is OK. But once the update is 
complete, the extra information let's us know when to start paying attention 
again.

Cheers,
-Steve