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:04:08PM -0800, Andy Lutomirski wrote:
> On Thu, Nov 8, 2018 at 9:41 PM Matthew Bobrowski
> <mbobrowski@mbobrowski.org> wrote:
> >
> > 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).
> 
> Seems reasonable.
> 
> >
> > > 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.
> 
> OK.  You should probably add to your documentation that interpreters
> opened as a result of execve() and execveat() also set FAN_OPEN_EXEC.

Sure, I can add that as a clarifying point to the documentation. 

> 
> >
> > 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.
> 
> Are you sure?  Because I don't think that DSOs actually get
> __FMODE_EXEC set.  So I expect that, if you do:
> 
> $ /bin/echo foo
> 
> then you'll get FAN_OPEN_EXEC.  

Correct. If the marked object here was /bin/echo, then yes, doing
exactly that would result in a FAN_OPEN_EXEC as you're passing it to
execve, so __FMODE_EXEC is set in the open_flag accordingly.

> If, on the other hand, you do:
> 
> $ /lib64/ld-linux-x86-64.so.2 /bin/echo foo
> 
> then I think you will *not* get FAN_OPEN_EXEC.

Here, you're also correct. 

Remember though, FAN_OPEN_EXEC is set purely for an object that is
opened and contains __FMODE_EXEC in the open_flag. Thus, anything opened
via syscalls execve, execveat or uselib. In the above example, direct
execution via execve is performed on /lib64/ld-linux-x86-64.so.2 and the
object /bin/echo in this instance is passed to it as an argument. This 
results in an open/read !(open_flag & __FMODE_EXEC), as oppose to
execve. So here, providing that you have a mark placed on the loader,
you'd only get a FAN_OPEN_EXEC for that object and consequently nothing
for the program that has been passed to it as an argument. 

Events of type FAN_OPEN_EXEC will *not* be raised in the situation where
an interpreter reads data as input and subsequently results in arbitrary
computation. I've also made this explicitly clear in my supporting
documentation (man-pages). Not sure, whether this should also be added
to the changelog. Thoughts?

-- 
Matthew Bobrowski