From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.kernel.org ([198.145.29.99]:45326 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727485AbeKIPnW (ORCPT ); Fri, 9 Nov 2018 10:43:22 -0500 Received: from mail-wr1-f49.google.com (mail-wr1-f49.google.com [209.85.221.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 9798E20892 for ; Fri, 9 Nov 2018 06:04:21 +0000 (UTC) Received: by mail-wr1-f49.google.com with SMTP id j17-v6so575640wrq.11 for ; Thu, 08 Nov 2018 22:04:21 -0800 (PST) MIME-Version: 1.0 References: <05d2297ae76d5b7b00cc1d6af27b25e898e986c0.1541639254.git.mbobrowski@mbobrowski.org> <20181109054133.GC4202@workstation.internal.lab> In-Reply-To: <20181109054133.GC4202@workstation.internal.lab> From: Andy Lutomirski Date: Thu, 8 Nov 2018 22:04:08 -0800 Message-ID: Subject: Re: [PATCH v7 2/4] fanotify: introduce new event mask FAN_OPEN_EXEC To: mbobrowski@mbobrowski.org Cc: Andrew Lutomirski , Jan Kara , Amir Goldstein , Linux API , Linux FS Devel , Steve Grubb Content-Type: text/plain; charset="UTF-8" Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Thu, Nov 8, 2018 at 9:41 PM Matthew Bobrowski 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 > > 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.