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@xxxxxxxxxxxxxx> 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
