public inbox for linux-api@vger.kernel.org
 help / color / mirror / Atom feed
From: Jan Kara <jack@suse.cz>
To: Richard Guy Briggs <rgb@redhat.com>
Cc: Linux-Audit Mailing List <linux-audit@redhat.com>,
	LKML <linux-kernel@vger.kernel.org>,
	linux-fsdevel@vger.kernel.org, linux-api@vger.kernel.org,
	Paul Moore <paul@paul-moore.com>,
	Eric Paris <eparis@parisplace.org>,
	Steve Grubb <sgrubb@redhat.com>, Jan Kara <jack@suse.cz>,
	Amir Goldstein <amir73il@gmail.com>
Subject: Re: [PATCH v6 0/3] fanotify: Allow user space to pass back additional audit info
Date: Wed, 18 Jan 2023 19:24:55 +0100	[thread overview]
Message-ID: <20230118182455.fdcfsrdrj2u7f5ux@quack3> (raw)
In-Reply-To: <cover.1673989212.git.rgb@redhat.com>

On Tue 17-01-23 16:14:04, Richard Guy Briggs wrote:
> The Fanotify API can be used for access control by requesting permission
> event notification. The user space tooling that uses it may have a
> complicated policy that inherently contains additional context for the
> decision. If this information were available in the audit trail, policy
> writers can close the loop on debugging policy. Also, if this additional
> information were available, it would enable the creation of tools that
> can suggest changes to the policy similar to how audit2allow can help
> refine labeled security.
> 
> This patchset defines a new flag (FAN_INFO) and new extensions that
> define additional information which are appended after the response
> structure returned from user space on a permission event.  The appended
> information is organized with headers containing a type and size that
> can be delegated to interested subsystems.  One new information type is
> defined to audit the triggering rule number.  
> 
> A newer kernel will work with an older userspace and an older kernel
> will behave as expected and reject a newer userspace, leaving it up to
> the newer userspace to test appropriately and adapt as necessary.  This
> is done by providing a a fully-formed FAN_INFO extension but setting the
> fd to FAN_NOFD.  On a capable kernel, it will succeed but issue no audit
> record, whereas on an older kernel it will fail.
> 
> The audit function was updated to log the additional information in the
> AUDIT_FANOTIFY record. The following are examples of the new record
> format:
>   type=FANOTIFY msg=audit(1600385147.372:590): resp=2 fan_type=1 fan_info=3137 subj_trust=3 obj_trust=5
>   type=FANOTIFY msg=audit(1659730979.839:284): resp=1 fan_type=0 fan_info=3F subj_trust=? obj_trust=?

Everything looks fine to me in this patchset so once patch 3/3 gets ack
from audit guys, I'll merge the series to my tree. Thanks for your work!

								Honza

-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

      parent reply	other threads:[~2023-01-18 18:25 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-17 21:14 [PATCH v6 0/3] fanotify: Allow user space to pass back additional audit info Richard Guy Briggs
2023-01-17 21:14 ` [PATCH v6 1/3] fanotify: Ensure consistent variable type for response Richard Guy Briggs
2023-01-17 21:14 ` [PATCH v6 2/3] fanotify: define struct members to hold response decision context Richard Guy Briggs
2023-01-17 21:14 ` [PATCH v6 3/3] fanotify,audit: Allow audit to use the full permission event response Richard Guy Briggs
2023-01-18 18:34   ` Steve Grubb
2023-01-20 18:52     ` Paul Moore
2023-01-25 22:06       ` Richard Guy Briggs
2023-01-27 20:00         ` Paul Moore
2023-01-27 20:17           ` Steve Grubb
2023-01-20 18:58   ` Paul Moore
2023-01-25 22:11     ` Richard Guy Briggs
2023-01-27 20:02       ` Paul Moore
2023-01-18 18:24 ` Jan Kara [this message]

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=20230118182455.fdcfsrdrj2u7f5ux@quack3 \
    --to=jack@suse.cz \
    --cc=amir73il@gmail.com \
    --cc=eparis@parisplace.org \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-audit@redhat.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=paul@paul-moore.com \
    --cc=rgb@redhat.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox