On Thu 08-11-18 22:04:08, 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. I'm not sure I understand your concern (and thus need for documentation). In the following I assume you watch the whole system for fanotify events (you can restrict them to specific files / mount points / superblocks but that's besides the point of this discussion). If you do: ~> /bin/echo Then you get FAN_OPEN_EXEC event for '/bin/echo' file and nothing more. Similarly if you do: ~> cat /tmp/test.sh #!/bin/bash /bin/echo ~> /tmp/test.sh You will get FAN_OPEN_EXEC events for /tmp/test.sh and /bin/echo and nothing more. If you do: ~> /bin/sh /tmp/test.sh You will get FAN_OPEN_EXEC events for /bin/sh and /bin/echo and nothing more. I other words generated FAN_OPEN_EXEC events 1:1 correspond to the first argument of the execve(2) syscall. Nothing less and nothing more. > > 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. Exactly and I think that was what Matthew was trying to tell. Generally there are no FAN_OPEN_EXEC events for DSOs. Is it clearer now? Honza -- Jan Kara <jack@xxxxxxxx> SUSE Labs, CR
