On Thu, Nov 8, 2018 at 9:41 PM Matthew Bobrowski <mbobrowski@xxxxxxxxxxxxxx> 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@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). 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. > > 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. 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.
