All of lore.kernel.org
 help / color / mirror / Atom feed
From: Matthew Bobrowski <mbobrowski@mbobrowski.org>
To: jack@suse.cz
Cc: amir73il@gmail.com, linux-api@vger.kernel.org,
	linux-fsdevel@vger.kernel.org, sgrubb@redhat.com
Subject: [PATCH v7 0/4] fanotify: introduce new event mask FAN_OPEN_EXEC and FAN_OPEN_EXEC_PERM
Date: Thu, 8 Nov 2018 14:04:10 +1100	[thread overview]
Message-ID: <cover.1541639254.git.mbobrowski@mbobrowski.org> (raw)

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 masks FAN_OPEN_EXEC and FAN_OPEN_EXEC_PERM have
been introduced in order to provide users with 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 v6:
	* Reordered patches within the patch series for the sake of
	  correctness.
	* Updated patch that contains FAN_OPEN_EXEC_PERM functionality to
	  include separate call to fsnotify_parent()/fsnotify() which is
	  used to mitigate merging of permission events.

Note that this set of patches are based on Amir's fsnotify-fixes branch,
which has already been posted through for review. For those interested,
this branch can be found here:
https://github.com/amir73il/linux/commits/fsnotify-fixes

LTP tests for this feature are on my 'fanotify-exec' branch here:
https://github.com/matthewbobrowski/ltp/commits/fanotify_exec. The files
that contains the test cases are provided below:

syscalls/fanotify03: test cases have been updated to cover
                     FAN_OPEN_EXEC_PERM events
syscalls/fanotify12: newly introduced LTP test file to cover
                     FAN_OPEN_EXEC events

All LTP tests have been run against this series of patches and all are
returning as a pass.

The man pages updates for these newly defined event masks can be found
here:
https://github.com/matthewbobrowski/man-pages/commits/fanotify_exec

I would like to thank both Amir and Jan for their time and help, highly
appreciated once again.

Matthew Bobrowski (4):
  fanotify: return only user requested event types in event mask
  fanotify: introduce new event mask FAN_OPEN_EXEC
  fsnotify: refactor fsnotify_parent()/fsnotify() paired calls when
    event is on path
  fanotify: introduce new event mask FAN_OPEN_EXEC_PERM

 fs/notify/fanotify/fanotify.c    | 29 ++++++++-------
 fs/notify/fsnotify.c             |  2 +-
 include/linux/fanotify.h         |  5 +--
 include/linux/fsnotify.h         | 61 +++++++++++++++++++-------------
 include/linux/fsnotify_backend.h | 11 ++++--
 include/uapi/linux/fanotify.h    |  2 ++
 6 files changed, 67 insertions(+), 43 deletions(-)

-- 
2.17.2


-- 
Matthew Bobrowski

             reply	other threads:[~2018-11-08 12:37 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-08  3:04 Matthew Bobrowski [this message]
2018-11-08  3:05 ` [PATCH v7 1/4] fanotify: return only user requested event types in event mask Matthew Bobrowski
2018-11-13 17:38   ` Jan Kara
2018-11-13 17:53     ` Amir Goldstein
2018-11-13 23:54       ` Matthew Bobrowski
2018-11-14 12:04         ` Jan Kara
2018-11-08  3:07 ` [PATCH v7 2/4] fanotify: introduce new event mask FAN_OPEN_EXEC Matthew Bobrowski
2018-11-08 18:22   ` Andy Lutomirski
2018-11-09  5:41     ` Matthew Bobrowski
2018-11-09  6:04       ` Andy Lutomirski
2018-11-09  7:27         ` Matthew Bobrowski
2018-11-12 16:14         ` Jan Kara
2018-11-12 16:37           ` Andy Lutomirski
2018-11-13 11:45             ` Matthew Bobrowski
2018-11-13 17:35               ` Jan Kara
2018-11-13 23:26                 ` Matthew Bobrowski
2018-11-08  3:10 ` [PATCH v7 3/4] fsnotify: refactor fsnotify_parent()/fsnotify() paired calls when event is on path Matthew Bobrowski
2018-11-08  3:12 ` [PATCH v7 4/4] fanotify: introduce new event mask FAN_OPEN_EXEC_PERM Matthew Bobrowski
2018-11-13 17:53 ` [PATCH v7 0/4] fanotify: introduce new event mask FAN_OPEN_EXEC and FAN_OPEN_EXEC_PERM Jan Kara
2018-11-13 18:01   ` Amir Goldstein
2018-11-14  3:43     ` Amir Goldstein
2018-11-14 12:02       ` Jan Kara
2018-11-14 15:54         ` Amir Goldstein
2018-11-19 10:27         ` Matthew Bobrowski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=cover.1541639254.git.mbobrowski@mbobrowski.org \
    --to=mbobrowski@mbobrowski.org \
    --cc=amir73il@gmail.com \
    --cc=jack@suse.cz \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=sgrubb@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.