All of lore.kernel.org
 help / color / mirror / Atom feed
From: Steve Grubb <sgrubb@redhat.com>
To: Linux-Audit Mailing List <linux-audit@redhat.com>,
	LKML <linux-kernel@vger.kernel.org>,
	linux-fsdevel@vger.kernel.org, linux-api@vger.kernel.org,
	Richard Guy Briggs <rgb@redhat.com>
Cc: Paul Moore <paul@paul-moore.com>,
	Eric Paris <eparis@parisplace.org>,
	Richard Guy Briggs <rgb@redhat.com>, Jan Kara <jack@suse.cz>,
	Amir Goldstein <amir73il@gmail.com>
Subject: Re: [PATCH v7 0/3] fanotify: Allow user space to pass back additional audit info
Date: Mon, 06 Feb 2023 17:52:20 -0500	[thread overview]
Message-ID: <12168436.O9o76ZdvQC@x2> (raw)
In-Reply-To: <cover.1675373475.git.rgb@redhat.com>

Hello Richard,

On Friday, February 3, 2023 4:35:13 PM EST 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.

I have taken the patches and built a new kernel. Everything looks good to me 
on the audit side. It's acting as expected. You can put me down for an ACK or 
tested-by or whatever is appropriate.

-Steve

> 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=0 subj_trust=2
> obj_trust=2
> 
> changelog:
> v1:
> - first version by Steve Grubb <sgrubb@redhat.com>
> Link: https://lore.kernel.org/r/2042449.irdbgypaU6@x2
> 
> v2:
> - enhancements suggested by Jan Kara <jack@suse.cz>
> - 1/3 change %d to %u in pr_debug
> - 2/3 change response from __u32 to __u16
> - mod struct fanotify_response and fanotify_perm_event add extra_info_type,
> extra_info_buf - extra_info_buf size max FANOTIFY_MAX_RESPONSE_EXTRA_LEN,
> add struct fanotify_response_audit_rule - extend debug statements
> - remove unneeded macros
> - [internal] change interface to finish_permission_event() and
> process_access_response() - 3/3 update format of extra information
> - [internal] change interface to audit_fanotify()
> - change ctx_type= to fan_type=
> Link: https://lore.kernel.org/r/cover.1651174324.git.rgb@redhat.com
> 
> v3:
> - 1/3 switch {,__}audit_fanotify() from uint to u32
> - 2/3 re-add fanotify_get_response switch case FAN_DENY: to avoid
> unnecessary churn - add FAN_EXTRA flag to indicate more info and break
> with old kernel - change response from u16 to u32 to avoid endian issues
> - change extra_info_buf to union
> - move low-cost fd check earlier
> - change FAN_RESPONSE_INFO_AUDIT_NONE to FAN_RESPONSE_INFO_NONE
> - switch to u32 for internal and __u32 for uapi
> Link: https://lore.kernel.org/all/cover.1652730821.git.rgb@redhat.com
> 
> v4:
> - scrap FAN_INVALID_RESPONSE_MASK in favour of original to catch invalid
> response == 0 - introduce FANOTIFY_RESPONSE_* macros
> - uapi: remove union
> - keep original struct fanotify_response, add fan_info infra starting with
> audit reason - uapi add struct fanotify_response_info_header{type/pad/len}
> and struct fanotify_response_info_audit_rule{hdr/rule} - rename fan_ctx=
> to fan_info=, FAN_EXTRA to FAN_INFO
> - change event struct from type/buf to len/buf
> - enable multiple info extensions in one message
> - hex encode fan_info in __audit_fanotify()
> - record type FANOTIFY extended to "type=FANOTIFY
> msg=audit(1659730979.839:284): resp=1 fan_type=0 fan_info=3F" Link:
> https://lore.kernel.org/all/cover.1659996830.git.rgb@redhat.com
> 
> v5:
> - fixed warnings in p2/4 and p3/4 found by <lkp@intel.com>
> - restore original behaviour for !FAN_INFO case and fanotify_get_response()
> - rename member audit_rule to rule_number
> - eliminate memory leak of info_buf on failure (no longer dynamic)
> - rename buf:info, count:info_len, c:remain, ib:infop
> - fix pr_debug
> - return -ENOENT on FAN_INFO and fd==FAN_NOFD to signal new kernel
> - fanotify_write() remove redundant size check
> - add u32 subj_trust obj_trust fields with unknown value "2"
> - split out to helper process_access_response_info()
> - restore finish_permission_event() response_struct to u32
> - assume and enforce one rule to audit, pass struct directly to
> __audit_fanotify() - change fanotify_perm_event struct to union
> hdr/audir_rule
> - add vspace to fanotify_write() and process_access_response_info()
> - squash 3/4 with 4/4
> - fix v3 and v4 links
> Link: https://lore.kernel.org/all/cover.1670606054.git.rgb@redhat.com
> 
> v6:
> - simplify __audit_fanotify() from audit_log_format/audit_log_n_hex to
> audit_log/%X - add comment to clarify {subj,obj}_trust values
> - remove fd processing from process_access_response_info()
> - return info_len immediately from process_access_response() on FAN_NOFD
> after process_access_response_info() Link:
> https://lore.kernel.org/all/cover.1673989212.git.rgb@redhat.com
> 
> v7:
> - change non FAN_INFO case to "0"
> - change from if-return to switch(type)-case, which now ignores non-audit
> info Link: https://lore.kernel.org/all/cover.1675373475.git.rgb@redhat.com
> 
> Richard Guy Briggs (3):
>   fanotify: Ensure consistent variable type for response
>   fanotify: define struct members to hold response decision context
>   fanotify,audit: Allow audit to use the full permission event response
> 
>  fs/notify/fanotify/fanotify.c      |  8 ++-
>  fs/notify/fanotify/fanotify.h      |  6 +-
>  fs/notify/fanotify/fanotify_user.c | 88 ++++++++++++++++++++++--------
>  include/linux/audit.h              |  9 +--
>  include/linux/fanotify.h           |  5 ++
>  include/uapi/linux/fanotify.h      | 30 +++++++++-
>  kernel/auditsc.c                   | 18 +++++-
>  7 files changed, 131 insertions(+), 33 deletions(-)





WARNING: multiple messages have this Message-ID (diff)
From: Steve Grubb <sgrubb@redhat.com>
To: Linux-Audit Mailing List <linux-audit@redhat.com>,
	LKML <linux-kernel@vger.kernel.org>,
	linux-fsdevel@vger.kernel.org, linux-api@vger.kernel.org,
	Richard Guy Briggs <rgb@redhat.com>
Cc: Richard Guy Briggs <rgb@redhat.com>,
	Eric Paris <eparis@parisplace.org>,
	Amir Goldstein <amir73il@gmail.com>, Jan Kara <jack@suse.cz>
Subject: Re: [PATCH v7 0/3] fanotify: Allow user space to pass back additional audit info
Date: Mon, 06 Feb 2023 17:52:20 -0500	[thread overview]
Message-ID: <12168436.O9o76ZdvQC@x2> (raw)
In-Reply-To: <cover.1675373475.git.rgb@redhat.com>

Hello Richard,

On Friday, February 3, 2023 4:35:13 PM EST 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.

I have taken the patches and built a new kernel. Everything looks good to me 
on the audit side. It's acting as expected. You can put me down for an ACK or 
tested-by or whatever is appropriate.

-Steve

> 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=0 subj_trust=2
> obj_trust=2
> 
> changelog:
> v1:
> - first version by Steve Grubb <sgrubb@redhat.com>
> Link: https://lore.kernel.org/r/2042449.irdbgypaU6@x2
> 
> v2:
> - enhancements suggested by Jan Kara <jack@suse.cz>
> - 1/3 change %d to %u in pr_debug
> - 2/3 change response from __u32 to __u16
> - mod struct fanotify_response and fanotify_perm_event add extra_info_type,
> extra_info_buf - extra_info_buf size max FANOTIFY_MAX_RESPONSE_EXTRA_LEN,
> add struct fanotify_response_audit_rule - extend debug statements
> - remove unneeded macros
> - [internal] change interface to finish_permission_event() and
> process_access_response() - 3/3 update format of extra information
> - [internal] change interface to audit_fanotify()
> - change ctx_type= to fan_type=
> Link: https://lore.kernel.org/r/cover.1651174324.git.rgb@redhat.com
> 
> v3:
> - 1/3 switch {,__}audit_fanotify() from uint to u32
> - 2/3 re-add fanotify_get_response switch case FAN_DENY: to avoid
> unnecessary churn - add FAN_EXTRA flag to indicate more info and break
> with old kernel - change response from u16 to u32 to avoid endian issues
> - change extra_info_buf to union
> - move low-cost fd check earlier
> - change FAN_RESPONSE_INFO_AUDIT_NONE to FAN_RESPONSE_INFO_NONE
> - switch to u32 for internal and __u32 for uapi
> Link: https://lore.kernel.org/all/cover.1652730821.git.rgb@redhat.com
> 
> v4:
> - scrap FAN_INVALID_RESPONSE_MASK in favour of original to catch invalid
> response == 0 - introduce FANOTIFY_RESPONSE_* macros
> - uapi: remove union
> - keep original struct fanotify_response, add fan_info infra starting with
> audit reason - uapi add struct fanotify_response_info_header{type/pad/len}
> and struct fanotify_response_info_audit_rule{hdr/rule} - rename fan_ctx=
> to fan_info=, FAN_EXTRA to FAN_INFO
> - change event struct from type/buf to len/buf
> - enable multiple info extensions in one message
> - hex encode fan_info in __audit_fanotify()
> - record type FANOTIFY extended to "type=FANOTIFY
> msg=audit(1659730979.839:284): resp=1 fan_type=0 fan_info=3F" Link:
> https://lore.kernel.org/all/cover.1659996830.git.rgb@redhat.com
> 
> v5:
> - fixed warnings in p2/4 and p3/4 found by <lkp@intel.com>
> - restore original behaviour for !FAN_INFO case and fanotify_get_response()
> - rename member audit_rule to rule_number
> - eliminate memory leak of info_buf on failure (no longer dynamic)
> - rename buf:info, count:info_len, c:remain, ib:infop
> - fix pr_debug
> - return -ENOENT on FAN_INFO and fd==FAN_NOFD to signal new kernel
> - fanotify_write() remove redundant size check
> - add u32 subj_trust obj_trust fields with unknown value "2"
> - split out to helper process_access_response_info()
> - restore finish_permission_event() response_struct to u32
> - assume and enforce one rule to audit, pass struct directly to
> __audit_fanotify() - change fanotify_perm_event struct to union
> hdr/audir_rule
> - add vspace to fanotify_write() and process_access_response_info()
> - squash 3/4 with 4/4
> - fix v3 and v4 links
> Link: https://lore.kernel.org/all/cover.1670606054.git.rgb@redhat.com
> 
> v6:
> - simplify __audit_fanotify() from audit_log_format/audit_log_n_hex to
> audit_log/%X - add comment to clarify {subj,obj}_trust values
> - remove fd processing from process_access_response_info()
> - return info_len immediately from process_access_response() on FAN_NOFD
> after process_access_response_info() Link:
> https://lore.kernel.org/all/cover.1673989212.git.rgb@redhat.com
> 
> v7:
> - change non FAN_INFO case to "0"
> - change from if-return to switch(type)-case, which now ignores non-audit
> info Link: https://lore.kernel.org/all/cover.1675373475.git.rgb@redhat.com
> 
> Richard Guy Briggs (3):
>   fanotify: Ensure consistent variable type for response
>   fanotify: define struct members to hold response decision context
>   fanotify,audit: Allow audit to use the full permission event response
> 
>  fs/notify/fanotify/fanotify.c      |  8 ++-
>  fs/notify/fanotify/fanotify.h      |  6 +-
>  fs/notify/fanotify/fanotify_user.c | 88 ++++++++++++++++++++++--------
>  include/linux/audit.h              |  9 +--
>  include/linux/fanotify.h           |  5 ++
>  include/uapi/linux/fanotify.h      | 30 +++++++++-
>  kernel/auditsc.c                   | 18 +++++-
>  7 files changed, 131 insertions(+), 33 deletions(-)




--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit


  parent reply	other threads:[~2023-02-06 22:54 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-03 21:35 [PATCH v7 0/3] fanotify: Allow user space to pass back additional audit info Richard Guy Briggs
2023-02-03 21:35 ` Richard Guy Briggs
2023-02-03 21:35 ` [PATCH v7 1/3] fanotify: Ensure consistent variable type for response Richard Guy Briggs
2023-02-03 21:35   ` Richard Guy Briggs
2023-02-03 21:35 ` [PATCH v7 2/3] fanotify: define struct members to hold response decision context Richard Guy Briggs
2023-02-03 21:35   ` Richard Guy Briggs
2023-02-03 21:35 ` [PATCH v7 3/3] fanotify,audit: Allow audit to use the full permission event response Richard Guy Briggs
2023-02-03 21:35   ` [PATCH v7 3/3] fanotify, audit: " Richard Guy Briggs
2023-02-06 22:52 ` Steve Grubb [this message]
2023-02-06 22:52   ` [PATCH v7 0/3] fanotify: Allow user space to pass back additional audit info Steve Grubb
2023-02-07 12:09 ` Jan Kara
2023-02-07 12:09   ` Jan Kara
2023-02-07 14:54   ` Paul Moore
2023-02-07 14:54     ` Paul Moore
2023-02-08 12:08     ` Jan Kara
2023-02-08 12:08       ` Jan Kara
2023-02-08 15:03       ` Paul Moore
2023-02-08 15:03         ` Paul Moore
2023-02-08 15:27         ` Steve Grubb
2023-02-08 15:27           ` Steve Grubb
2023-02-08 16:24           ` Paul Moore
2023-02-08 16:24             ` Paul Moore
2023-02-08 17:37             ` Richard Guy Briggs
2023-02-08 17:37               ` Richard Guy Briggs
2023-02-08 18:53               ` Paul Moore
2023-02-08 18:53                 ` Paul Moore
2023-02-09  9:07         ` Jan Kara
2023-02-09  9:07           ` Jan Kara

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=12168436.O9o76ZdvQC@x2 \
    --to=sgrubb@redhat.com \
    --cc=amir73il@gmail.com \
    --cc=eparis@parisplace.org \
    --cc=jack@suse.cz \
    --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 \
    /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.