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