| Message ID | cover.1539758834.git.mbobrowski@mbobrowski.org (mailing list archive) |
|---|---|
| Headers | show |
| Series | fanotify: introduce new event types FAN_OPEN_EXEC and FAN_OPEN_EXEC_PERM | expand |
On Wed 17-10-18 20:04:37, Matthew Bobrowski wrote: > Currently, the fanotify API does not provide a means for user space > applications to receive events when a file has been opened specifically > for execution. New event types FAN_OPEN_EXEC and FAN_OPEN_EXEC_PERM have > been introduced in order to provide users this capability. OK, so these patches look mostly ready (except for a small bits I've commented on patch 3). How about the LTP test to actually test them? Once that exists, I can test the patches and merge them into my tree... Honza
On Wed, Oct 17, 2018 at 12:04 PM Matthew Bobrowski <mbobrowski@mbobrowski.org> wrote: > > Please note that all modifications here are based on the changes Amir has > made around deprecating some of the previously exposed UAPI constants. The > branch which my changes are based on can be found here: > > https://github.com/amir73il/linux/tree/fanotify_api-v3 > Matthew, Please note that this branch is slightly outdated. When testing you should rebase your patches on top of git://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs.git fsnotify I don't think that you need to re-post unless Jan wants a re-post of patch #3 because there shouldn't be any rebase conflicts. Thanks, Amir.
On Thu, Oct 18, 2018 at 11:28:21AM +0200, Jan Kara wrote: > On Wed 17-10-18 20:04:37, Matthew Bobrowski wrote: > > Currently, the fanotify API does not provide a means for user space > > applications to receive events when a file has been opened specifically > > for execution. New event types FAN_OPEN_EXEC and FAN_OPEN_EXEC_PERM have > > been introduced in order to provide users this capability. > > OK, so these patches look mostly ready (except for a small bits I've > commented on patch 3). OK, great. I can go ahead and perform the necessary updates. These are minor though, so I'm not sure whether it's appropriate to actually send through and entire new patch series that include these changes? To be fair I'm not entirely sure how you're meant to really submit through these minor updates based on previous reviews... > How about the LTP test to actually test them? Once that exists, I can > test the patches and merge them into my tree... Yes, I'm working on them at the moment. I've got some time coming up this weekend, so I hope to have them ready for you by then. It's a little fiddly when it comes to incorporating the exec events into previous tests. The way they're currently written doesn't really allow for them to be somewhat extensible in my opinion. I've written a new test in a completely separate test file, which is easy enough; however I think that these new event types should most definitely be part of perviously written tests i.e. fanotify03 for FAN_OPEN_EXEC_PERM. I've discussed this with Amir and he also agrees.
On Thu, Oct 18, 2018 at 01:07:37PM +0300, Amir Goldstein wrote: > On Wed, Oct 17, 2018 at 12:04 PM Matthew Bobrowski > <mbobrowski@mbobrowski.org> wrote: > > > > Please note that all modifications here are based on the changes Amir has > > made around deprecating some of the previously exposed UAPI constants. The > > branch which my changes are based on can be found here: > > > > https://github.com/amir73il/linux/tree/fanotify_api-v3 > > > > Please note that this branch is slightly outdated. > When testing you should rebase your patches on top of > git://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs.git fsnotify Perfect, and will do. Thanks for sending that through. > I don't think that you need to re-post unless Jan wants a re-post of patch #3 > because there shouldn't be any rebase conflicts. Yeah, that's what I mentioned within my previous email. I mean, the ammendments to these files are minimal, so I don't really know whether I need to submit a completely new patch series through for each update after a review? Happy to re-post, if required.
On Thu 18-10-18 23:06:16, Matthew Bobrowski wrote: > On Thu, Oct 18, 2018 at 11:28:21AM +0200, Jan Kara wrote: > > On Wed 17-10-18 20:04:37, Matthew Bobrowski wrote: > > > Currently, the fanotify API does not provide a means for user space > > > applications to receive events when a file has been opened specifically > > > for execution. New event types FAN_OPEN_EXEC and FAN_OPEN_EXEC_PERM have > > > been introduced in order to provide users this capability. > > > > OK, so these patches look mostly ready (except for a small bits I've > > commented on patch 3). > > OK, great. I can go ahead and perform the necessary updates. These are > minor though, so I'm not sure whether it's appropriate to actually send > through and entire new patch series that include these changes? To be fair > I'm not entirely sure how you're meant to really submit through these > minor updates based on previous reviews... I guess I can just make the changes when picking up patches. > > How about the LTP test to actually test them? Once that exists, I can > > test the patches and merge them into my tree... > > Yes, I'm working on them at the moment. I've got some time coming up this > weekend, so I hope to have them ready for you by then. It's a little > fiddly when it comes to incorporating the exec events into previous tests. > The way they're currently written doesn't really allow for them to be > somewhat extensible in my opinion. I've written a new test in a completely > separate test file, which is easy enough; however I think that these new > event types should most definitely be part of perviously written tests > i.e. fanotify03 for FAN_OPEN_EXEC_PERM. I've discussed this with Amir and > he also agrees. Yeah, that would be nice. Honza
Hi Jan, On Thu, Oct 18, 2018 at 02:48:36PM +0200, Jan Kara wrote: > On Thu 18-10-18 23:06:16, Matthew Bobrowski wrote: > > On Thu, Oct 18, 2018 at 11:28:21AM +0200, Jan Kara wrote: > > > On Wed 17-10-18 20:04:37, Matthew Bobrowski wrote: > > > > Currently, the fanotify API does not provide a means for user space > > > > applications to receive events when a file has been opened specifically > > > > for execution. New event types FAN_OPEN_EXEC and FAN_OPEN_EXEC_PERM have > > > > been introduced in order to provide users this capability. > > > > > > OK, so these patches look mostly ready (except for a small bits I've > > > commented on patch 3). > > > > OK, great. I can go ahead and perform the necessary updates. These are > > minor though, so I'm not sure whether it's appropriate to actually send > > through and entire new patch series that include these changes? To be fair > > I'm not entirely sure how you're meant to really submit through these > > minor updates based on previous reviews... > > I guess I can just make the changes when picking up patches. If you like, you may obtain a copy of patch 3 for this patch series from the link I've provided below. It contains the minor update around adding FS_OPEN_EXEC_PERM to ALL_FSNOTIFY_PERM_EVENTS. Saves you having to remember to do it when applying the patches to your tree. https://mbobrowski.org/patches/kernel/0003-fanotify.patch
Currently, the fanotify API does not provide a means for user space applications to receive events when a file has been opened specifically for execution. New event types FAN_OPEN_EXEC and FAN_OPEN_EXEC_PERM have been introduced in order to provide users this capability. These event types, when either are explicitly requested by the user, will be returned within the event mask when a marked file object is being opened has __FMODE_EXEC set as one of the flags for open_flag. 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 administrator specified [selection: file path, file digital signature, version, hash, [assignment: other characteristics] ] This patch is to help aid in meeting this requirement. Changes since v4: Thanks to both Amir and Jan for the review, much appreciated! * Patch 1: "fanotify: introduce new event type FAN_OPEN_EXEC" * Updated the changelog to clarify that the event type FAN_OPEN_EXEC is set only when a file is opened using the syscalls execve(), execveat() or uselib() * Patch 2: "fanotify: return only user requested event types in event mask" * Rectified grammar issues within commit message * Rectified spelling and grammer issues within the function comment * Updated fanotify_hande_event() so that the value returned from fanotify_group_event_mask() stores the result in the existing 'mask' variable as oppose to a newly created variable * Patch 3: "fanotify: introduce new event type FAN_OPEN_EXEC_PERM" * Updated the changelog to clarify that the event FAN_OPEN_EXEC_PERM is set only when a fie is opened using the syscalls execve(), execveat() or uselib() I've also written the required updates for the man-pages project. It includes descriptions about the newly available event types and some additional notes around what actions will see these flags. You can find the changes here: https://github.com/matthewbobrowski/man-pages/commit/d075dd8c8dfe19fccb9ea91f9550ea41b6e67334 Please note that all modifications here are based on the changes Amir has made around deprecating some of the previously exposed UAPI constants. The branch which my changes are based on can be found here: https://github.com/amir73il/linux/tree/fanotify_api-v3 --- Matthew Bobrowski (3): fanotify: introduce new event type FAN_OPEN_EXEC fanotify: return only user requested event types in event mask fanotify: introduce new event type FAN_OPEN_EXEC_PERM fs/notify/fanotify/fanotify.c | 34 +++++++++++++++++++------------- fs/notify/fsnotify.c | 2 +- include/linux/fanotify.h | 5 +++-- include/linux/fsnotify.h | 12 +++++++---- include/linux/fsnotify_backend.h | 10 +++++++--- include/uapi/linux/fanotify.h | 2 ++ 6 files changed, 41 insertions(+), 24 deletions(-)