From: Richard Guy Briggs <rgb@redhat.com> To: Linux-Audit Mailing List <linux-audit@redhat.com>, LKML <linux-kernel@vger.kernel.org>, linux-fsdevel@vger.kernel.org Cc: Paul Moore <paul@paul-moore.com>, Eric Paris <eparis@parisplace.org>, Steve Grubb <sgrubb@redhat.com>, Richard Guy Briggs <rgb@redhat.com>, Jan Kara <jack@suse.cz>, Amir Goldstein <amir73il@gmail.com> Subject: [PATCH v4 0/4] fanotify: Allow user space to pass back additional audit info Date: Tue, 9 Aug 2022 13:22:51 -0400 [thread overview] Message-ID: <cover.1659996830.git.rgb@redhat.com> (raw) 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 for audit 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. The audit function was updated to log the additional information in the AUDIT_FANOTIFY record. The following is an example of the new record format: type=FANOTIFY msg=audit(1600385147.372:590): resp=2 fan_type=1 fan_info=3F 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/r/cover.1652724390.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/r/cover.1659981772.git.rgb@redhat.com Richard Guy Briggs (4): 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 fanotify,audit: deliver fan_info as a hex-encoded string fs/notify/fanotify/fanotify.c | 13 +++- fs/notify/fanotify/fanotify.h | 4 +- fs/notify/fanotify/fanotify_user.c | 106 ++++++++++++++++++++++------- include/linux/audit.h | 9 +-- include/linux/fanotify.h | 5 ++ include/uapi/linux/fanotify.h | 27 +++++++- kernel/auditsc.c | 45 +++++++++++- 7 files changed, 174 insertions(+), 35 deletions(-) -- 2.27.0
WARNING: multiple messages have this Message-ID (diff)
From: Richard Guy Briggs <rgb@redhat.com> To: Linux-Audit Mailing List <linux-audit@redhat.com>, LKML <linux-kernel@vger.kernel.org>, linux-fsdevel@vger.kernel.org Cc: Jan Kara <jack@suse.cz>, Richard Guy Briggs <rgb@redhat.com>, Amir Goldstein <amir73il@gmail.com>, Eric Paris <eparis@parisplace.org> Subject: [PATCH v4 0/4] fanotify: Allow user space to pass back additional audit info Date: Tue, 9 Aug 2022 13:22:51 -0400 [thread overview] Message-ID: <cover.1659996830.git.rgb@redhat.com> (raw) 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 for audit 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. The audit function was updated to log the additional information in the AUDIT_FANOTIFY record. The following is an example of the new record format: type=FANOTIFY msg=audit(1600385147.372:590): resp=2 fan_type=1 fan_info=3F 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/r/cover.1652724390.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/r/cover.1659981772.git.rgb@redhat.com Richard Guy Briggs (4): 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 fanotify,audit: deliver fan_info as a hex-encoded string fs/notify/fanotify/fanotify.c | 13 +++- fs/notify/fanotify/fanotify.h | 4 +- fs/notify/fanotify/fanotify_user.c | 106 ++++++++++++++++++++++------- include/linux/audit.h | 9 +-- include/linux/fanotify.h | 5 ++ include/uapi/linux/fanotify.h | 27 +++++++- kernel/auditsc.c | 45 +++++++++++- 7 files changed, 174 insertions(+), 35 deletions(-) -- 2.27.0 -- Linux-audit mailing list Linux-audit@redhat.com https://listman.redhat.com/mailman/listinfo/linux-audit
next reply other threads:[~2022-08-09 17:23 UTC|newest] Thread overview: 91+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-08-09 17:22 Richard Guy Briggs [this message] 2022-08-09 17:22 ` [PATCH v4 0/4] fanotify: Allow user space to pass back additional audit info Richard Guy Briggs 2022-08-09 17:22 ` [PATCH v4 1/4] fanotify: Ensure consistent variable type for response Richard Guy Briggs 2022-08-09 17:22 ` Richard Guy Briggs 2022-08-09 17:22 ` [PATCH v4 2/4] fanotify: define struct members to hold response decision context Richard Guy Briggs 2022-08-09 17:22 ` Richard Guy Briggs 2022-08-10 6:22 ` Amir Goldstein 2022-08-10 6:22 ` Amir Goldstein 2022-08-19 11:24 ` Jan Kara 2022-08-19 11:24 ` Jan Kara 2022-08-10 14:28 ` kernel test robot 2022-08-10 14:28 ` kernel test robot 2022-08-19 16:25 ` Richard Guy Briggs 2022-08-19 16:25 ` Richard Guy Briggs 2022-08-19 16:25 ` Richard Guy Briggs 2022-08-19 17:17 ` Nick Desaulniers 2022-08-19 17:17 ` Nick Desaulniers 2022-08-19 17:17 ` Nick Desaulniers 2022-08-19 21:45 ` Richard Guy Briggs 2022-08-19 21:45 ` Richard Guy Briggs 2022-08-19 21:45 ` Richard Guy Briggs 2022-08-12 0:23 ` Matthew Bobrowski 2022-08-12 0:23 ` Matthew Bobrowski 2022-08-19 11:16 ` Jan Kara 2022-08-19 11:16 ` Jan Kara 2022-08-19 11:13 ` Jan Kara 2022-08-19 11:13 ` Jan Kara 2022-08-09 17:22 ` [PATCH v4 3/4] fanotify,audit: Allow audit to use the full permission event response Richard Guy Briggs 2022-08-09 17:22 ` [PATCH v4 3/4] fanotify, audit: " Richard Guy Briggs 2022-08-10 20:32 ` [PATCH v4 3/4] fanotify,audit: " kernel test robot 2022-08-10 20:32 ` kernel test robot 2022-08-16 0:22 ` Paul Moore 2022-08-16 0:22 ` Paul Moore 2022-08-31 21:07 ` Richard Guy Briggs 2022-08-31 21:07 ` Richard Guy Briggs 2022-08-31 21:25 ` Steve Grubb 2022-08-31 21:25 ` [PATCH v4 3/4] fanotify, audit: " Steve Grubb 2022-08-31 22:19 ` [PATCH v4 3/4] fanotify,audit: " Richard Guy Briggs 2022-08-31 22:19 ` Richard Guy Briggs 2022-08-31 23:55 ` Steve Grubb 2022-08-31 23:55 ` [PATCH v4 3/4] fanotify, audit: " Steve Grubb 2022-09-01 1:47 ` [PATCH v4 3/4] fanotify,audit: " Paul Moore 2022-09-01 1:47 ` Paul Moore 2022-09-01 7:51 ` Jan Kara 2022-09-01 7:51 ` Jan Kara 2022-09-01 18:31 ` Paul Moore 2022-09-01 18:31 ` Paul Moore 2022-09-07 18:43 ` Richard Guy Briggs 2022-09-07 18:43 ` Richard Guy Briggs 2022-09-07 20:11 ` Steve Grubb 2022-09-07 20:11 ` [PATCH v4 3/4] fanotify, audit: " Steve Grubb 2022-09-07 20:23 ` [PATCH v4 3/4] fanotify,audit: " Paul Moore 2022-09-07 20:23 ` Paul Moore 2022-09-08 21:14 ` Steve Grubb 2022-09-08 21:14 ` [PATCH v4 3/4] fanotify, audit: " Steve Grubb 2022-09-08 21:22 ` [PATCH v4 3/4] fanotify,audit: " Paul Moore 2022-09-08 21:22 ` Paul Moore 2022-09-09 2:20 ` Steve Grubb 2022-09-09 2:20 ` [PATCH v4 3/4] fanotify, audit: " Steve Grubb 2022-09-09 2:41 ` [PATCH v4 3/4] fanotify,audit: " Richard Guy Briggs 2022-09-09 2:41 ` Richard Guy Briggs 2022-09-09 3:25 ` Paul Moore 2022-09-09 3:25 ` Paul Moore 2022-09-09 4:03 ` Steve Grubb 2022-09-09 4:03 ` [PATCH v4 3/4] fanotify, audit: " Steve Grubb 2022-09-09 11:09 ` [PATCH v4 3/4] fanotify,audit: " Jan Kara 2022-09-09 11:09 ` Jan Kara 2022-09-09 14:22 ` Steve Grubb 2022-09-09 14:22 ` [PATCH v4 3/4] fanotify, audit: " Steve Grubb 2022-09-09 14:38 ` [PATCH v4 3/4] fanotify,audit: " Richard Guy Briggs 2022-09-09 14:38 ` Richard Guy Briggs 2022-09-09 14:55 ` Steve Grubb 2022-09-09 14:55 ` [PATCH v4 3/4] fanotify, audit: " Steve Grubb 2022-09-09 18:50 ` [PATCH v4 3/4] fanotify,audit: " Richard Guy Briggs 2022-09-09 18:50 ` Richard Guy Briggs 2022-08-09 17:22 ` [PATCH v4 4/4] fanotify,audit: deliver fan_info as a hex-encoded string Richard Guy Briggs 2022-08-09 17:22 ` [PATCH v4 4/4] fanotify, audit: " Richard Guy Briggs 2022-08-10 19:15 ` [PATCH v4 4/4] fanotify,audit: " Steve Grubb 2022-08-10 19:15 ` [PATCH v4 4/4] fanotify, audit: " Steve Grubb 2022-08-11 2:23 ` [PATCH v4 4/4] fanotify,audit: " Richard Guy Briggs 2022-08-11 2:23 ` [PATCH v4 4/4] fanotify, audit: " Richard Guy Briggs 2022-08-15 21:15 ` Steve Grubb 2022-08-15 21:15 ` [PATCH v4 4/4] fanotify,audit: " Steve Grubb 2022-08-16 0:31 ` [PATCH v4 4/4] fanotify, audit: " Paul Moore 2022-08-16 0:31 ` [PATCH v4 4/4] fanotify,audit: " Paul Moore 2022-08-16 13:37 ` Steve Grubb 2022-08-16 13:37 ` [PATCH v4 4/4] fanotify, audit: " Steve Grubb 2022-08-19 21:42 ` [PATCH v4 4/4] fanotify,audit: " Richard Guy Briggs 2022-08-19 21:42 ` [PATCH v4 4/4] fanotify, audit: " Richard Guy Briggs 2022-08-10 5:21 ` [PATCH v4 0/4] fanotify: Allow user space to pass back additional audit info Amir Goldstein 2022-08-10 5:21 ` Amir Goldstein
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.1659996830.git.rgb@redhat.com \ --to=rgb@redhat.com \ --cc=amir73il@gmail.com \ --cc=eparis@parisplace.org \ --cc=jack@suse.cz \ --cc=linux-audit@redhat.com \ --cc=linux-fsdevel@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=paul@paul-moore.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: linkBe 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.