Re: [PATCH v7 2/4] fanotify: introduce new event mask FAN_OPEN_EXEC

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





> On Nov 12, 2018, at 8:14 AM, Jan Kara <jack@xxxxxxx> wrote:
> 
>> 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.

If indeed that’s what the code does, then documenting it as such seems fine. But, by inspection, ELF interpreters are opened with open_exec(), so they should fire the event too. Am I wrong?






[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux