From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx2.suse.de ([195.135.220.15]:59066 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1728891AbeJARnc (ORCPT ); Mon, 1 Oct 2018 13:43:32 -0400 Date: Mon, 1 Oct 2018 13:06:15 +0200 From: Jan Kara To: Al Viro Cc: Jan Kara , amir73il@gmail.com, Steve Grubb , linux-fsdevel@vger.kernel.org, Matthew Bobrowski Subject: Re: [PATCH v2 1/1] fanotify: introduce new event flag FAN_EXEC Message-ID: <20181001110615.GH3913@quack2.suse.cz> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Thu 27-09-18 23:05:14, Matthew Bobrowski wrote: > This is a reduced version of a patch that I originally submitted a while ago. > > In short, the fanotify API currently does not provide any means for user space > programs to receive events specifically when a file has been opened with the > intent to be executed. The FAN_EXEC flag will be set within the event mask when > a object has been opened with one of the open flags being __FMODE_EXEC. > > Linux is used as an Operating System in some products, with an environment that > can be certified under the Common Criteria Operating System Protection Profile > (OSPP). This is a formal threat model for a class of technology. It requires > specific countermeasures to mitigate threats. It requires documentation to > explain how a product implements these countermeasures. It requires proof via a > test suite to demonstrate that the requirements are met, observed and checked by > an independent qualified third party. The latest set of requirements for OSPP > v4.2 can be found here: > > https://www.niap-ccevs.org/Profile/Info.cfm?PPID=424&id=424 > > If you look on page 58, you will see the following requirement: > > FPT_SRP_EXT.1 Software Restriction Policies FPT_SRP_EXT.1.1 > > The OS shall restrict execution to only programs which match an administrator > specified [selection: > file path, > file digital signature, > version, > hash, > [assignment: other characteristics] > ] > > This patch is to help aid in meeting this requirement. > > Signed-off-by: Matthew Bobrowski Al, I'd like your opinion on one thing below: > diff --git a/include/linux/fsnotify.h b/include/linux/fsnotify.h > index fd1ce10553bf..aad174c81322 100644 > --- a/include/linux/fsnotify.h > +++ b/include/linux/fsnotify.h > @@ -216,6 +216,9 @@ static inline void fsnotify_open(struct file *file) > if (S_ISDIR(inode->i_mode)) > mask |= FS_ISDIR; > > + if (file->f_flags & __FMODE_EXEC) > + mask |= FS_EXEC; > + > fsnotify_parent(path, NULL, mask); > fsnotify(inode, mask, path, FSNOTIFY_EVENT_PATH, NULL, 0); > } Audit guys want to detect when open happens as a result of a file being executed (some rationale in the changelog above). From filesystem notification POV it makes sense to me to report opens that require execute permission so in principle I'm OK with the functionality. But is it OK to use __FMODE_EXEC for this and thus effectively expose it to userspace? So far it is pretty much internal VFS flag and although it apparently has the right meaning (currently), I'm somewhat concerned that it may change in the future. Thanks. Honza -- Jan Kara SUSE Labs, CR