Re: [PATCH v7 2/4] fanotify: introduce new event mask FAN_OPEN_EXEC

[Matthew Bobrowski <mbobrowski@mbobrowski.org>]

On Thu, Nov 08, 2018 at 10:22:50AM -0800, Andy Lutomirski wrote:
> On Wed, Nov 7, 2018 at 7:07 PM Matthew Bobrowski
> <mbobrowski@mbobrowski.org> wrote:
> >
> > A new event mask FAN_OPEN_EXEC has been defined so that users have the
> > ability to receive events specifically when a file has been opened with
> > the intent to be executed. Events of FAN_OPEN_EXEC type will be
> > generated when a file has been opened using either execve(), execveat()
> > or uselib() system calls.
> >
> > The feature is implemented within fsnotify_open() by generating the
> > FAN_OPEN_EXEC event type if __FMODE_EXEC is set within file->f_flags.
> >
> 
> I think this needs some clarification.  In particular:

OK, sure.

> Do current kernels generate some other fanotify on execve or do they
> generate no event at all?

Yes, it does currently generate events on execve. Due to the nature of
how this particular system call works, the API, as is, will generate a
number of FAN_OPEN and FAN_ACCESS events.
 
> What is the intended use case?

For our particular use case, this is to greatly assist with an auditing
application that we're in the midst of developing. More specifically
though, it is to aid with providing additional context around why the
marked object(s) is being opened. We're interested to understand when
the direct execution of a file occurs via execve() or execveat(), for
example. This becomes exceptionally helpful on a busy filesystem when
you're trying to sift through and correlate FAN_OPEN and FAN_ACCESS
events while having marks placed on either a mount(s) or superblock(s).

> What semantics do you provide for the opening of the ELF loader?  Are
> those semantics useful?

I don't exactly understand what you mean by providing semantics around
the opening of the ELF loader. However, I'm going to work with the
assumption that you're referring to how this particular event mask works
with the implicit invocation of the ELF loader when an ELF program is
being prepared for execution? If that's the case, it's quite simple. If
the ELF loader has been marked to receive events of this type, then an
event will also be generated for the ELF loader when an ELF program is
invoked via execve. If the ELF loader has not been marked, then only the
event for the ELF program itself will be generated. 

If I've misunderstood what you're referring to, please kindly elaborate.
 
> How are users of this mechanism expected to handle DSOs?

Well, if they're concerned about the direct execution of a shared
library, then they'd just place a mark on it using this mask. Generally
speaking though, I can't see that being particularly useful seeing as
though DSOs in most cases are not actually directly executed per se, but
rather opened, read and then mapped into the process address space. So,
if they're concerned with handling DSOs, then it's the users discretion
about whether they mark it and what type of mark is to be placed on the
DSO object itself.

-- 
Matthew Bobrowski