On 2022-08-15 20:22, Paul Moore wrote:
On Tue, Aug 9, 2022 at 1:23 PM Richard Guy Briggs
<rgb(a)redhat.com> wrote:
>
> This patch passes the full value so that the audit function can use all
> of it. 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=17
>
> Suggested-by: Steve Grubb <sgrubb(a)redhat.com>
> Link:
https://lore.kernel.org/r/3075502.aeNJFYEL58@x2
> Signed-off-by: Richard Guy Briggs <rgb(a)redhat.com>
> ---
> fs/notify/fanotify/fanotify.c | 3 ++-
> include/linux/audit.h | 9 +++++----
> kernel/auditsc.c | 31 ++++++++++++++++++++++++++++---
> 3 files changed, 35 insertions(+), 8 deletions(-)
You've hopefully already seen the kernel test robot build warning, so
I won't bring that up again, but a few comments below ...
Yes, dealt with...
...
> diff --git a/kernel/auditsc.c b/kernel/auditsc.c
> index 433418d73584..f000fec52360 100644
> --- a/kernel/auditsc.c
> +++ b/kernel/auditsc.c
> @@ -64,6 +64,7 @@
> #include <uapi/linux/limits.h>
> #include <uapi/linux/netfilter/nf_tables.h>
> #include <uapi/linux/openat2.h> // struct open_how
> +#include <uapi/linux/fanotify.h>
>
> #include "audit.h"
>
> @@ -2899,10 +2900,34 @@ void __audit_log_kern_module(char *name)
> context->type = AUDIT_KERN_MODULE;
> }
>
> -void __audit_fanotify(u32 response)
> +void __audit_fanotify(u32 response, size_t len, char *buf)
> {
> - audit_log(audit_context(), GFP_KERNEL,
> - AUDIT_FANOTIFY, "resp=%u", response);
> + struct fanotify_response_info_audit_rule *friar;
> + size_t c = len;
> + char *ib = buf;
> +
> + if (!(len && buf)) {
> + audit_log(audit_context(), GFP_KERNEL, AUDIT_FANOTIFY,
> + "resp=%u fan_type=0 fan_info=?", response);
> + return;
> + }
> + while (c >= sizeof(struct fanotify_response_info_header)) {
> + friar = (struct fanotify_response_info_audit_rule *)buf;
Since the only use of this at the moment is the
fanotify_response_info_rule, why not pass the
fanotify_response_info_rule struct directly into this function? We
can always change it if we need to in the future without affecting
userspace, and it would simplify the code.
Steve, would it make any sense for there to be more than one
FAN_RESPONSE_INFO_AUDIT_RULE header in a message? Could there be more
than one rule that contributes to a notify reason? If not, would it be
reasonable to return -EINVAL if there is more than one?
> + switch (friar->hdr.type) {
> + case FAN_RESPONSE_INFO_AUDIT_RULE:
> + if (friar->hdr.len < sizeof(*friar)) {
> + audit_log(audit_context(), GFP_KERNEL,
AUDIT_FANOTIFY,
> + "resp=%u fan_type=%u
fan_info=(incomplete)",
> + response, friar->hdr.type);
> + return;
> + }
> + audit_log(audit_context(), GFP_KERNEL, AUDIT_FANOTIFY,
> + "resp=%u fan_type=%u fan_info=%u",
> + response, friar->hdr.type,
friar->audit_rule);
> + }
> + c -= friar->hdr.len;
> + ib += friar->hdr.len;
> + }
> }
>
> void __audit_tk_injoffset(struct timespec64 offset)
paul-moore.com
- RGB
--
Richard Guy Briggs <rgb(a)redhat.com>
Sr. S/W Engineer, Kernel Security, Base Operating Systems
Remote, Ottawa, Red Hat Canada
IRC: rgb, SunRaycer
Voice: +1.647.777.2635, Internal: (81) 32635