From: Richard Guy Briggs <rgb@redhat.com> To: Steve Grubb <sgrubb@redhat.com> Cc: Linux-Audit Mailing List <linux-audit@redhat.com>, LKML <linux-kernel@vger.kernel.org>, linux-fsdevel@vger.kernel.org, Paul Moore <paul@paul-moore.com>, Eric Paris <eparis@parisplace.org>, Jan Kara <jack@suse.cz>, Amir Goldstein <amir73il@gmail.com> Subject: Re: [PATCH v4 4/4] fanotify,audit: deliver fan_info as a hex-encoded string Date: Wed, 10 Aug 2022 22:23:49 -0400 [thread overview] Message-ID: <YvRoNSL0snBY87/b@madcap2.tricolour.ca> (raw) In-Reply-To: <5623945.DvuYhMxLoT@x2> On 2022-08-10 15:15, Steve Grubb wrote: > Hell Richard, That's quite an introduction! ;-) > On Tuesday, August 9, 2022 1:22:55 PM EDT Richard Guy Briggs wrote: > > Currently the only type of fanotify info that is defined is an audit > > rule number, but convert it to hex encoding to future-proof the field. > > > > Sample record: > > type=FANOTIFY msg=audit(1659730979.839:284): resp=1 fan_type=0 > > fan_info=3F > > I compiled a new kernel and run old user space on this. The above event is > exactly what I see in my audit logs. Why the fan_info=3F? I really would have > expected 0. What if the actual rule number was 63? I think this will work > better to leave everything 0 with old user space. Well, if it is to be consistently hex encoded, that corresponds to "?" if it is to be interpreted as a string. Since the fan_type is 0, fan_info would be invalid, so a value of 0 would be entirely reasonable, hex encoded to fan_info=00. It could also be hex encoded to the string "(none)". If you wanted "0" for fan_type=FAN_RESPONSE_INFO_AUDIT_RULE, that would be fan_info=30 if it were interpreted as a string, or arguably 3F for an integer of rule (decimal) 63. Ultimately, fan_type should determine how fan_info's hex encoded value should be interpreted. But ultimately, the point of this patch is to hex encode the fan_info field value. > -Steve > > > Suggested-by: Paul Moore <paul@paul-moore.com> > > Signed-off-by: Richard Guy Briggs <rgb@redhat.com> > > --- > > kernel/auditsc.c | 28 +++++++++++++++++++++------- > > 1 file changed, 21 insertions(+), 7 deletions(-) > > > > diff --git a/kernel/auditsc.c b/kernel/auditsc.c > > index f000fec52360..0f747015c577 100644 > > --- a/kernel/auditsc.c > > +++ b/kernel/auditsc.c > > @@ -2908,22 +2908,36 @@ void __audit_fanotify(u32 response, size_t len, > > char *buf) > > > > if (!(len && buf)) { > > audit_log(audit_context(), GFP_KERNEL, AUDIT_FANOTIFY, > > - "resp=%u fan_type=0 fan_info=?", response); > > + "resp=%u fan_type=0 fan_info=3F", response); /* "?" */ > > return; > > } > > while (c >= sizeof(struct fanotify_response_info_header)) { > > + struct audit_context *ctx = audit_context(); > > + struct audit_buffer *ab; > > + > > friar = (struct fanotify_response_info_audit_rule *)buf; > > 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); > > + ab = audit_log_start(ctx, GFP_KERNEL, AUDIT_FANOTIFY); > > + if (ab) { > > + audit_log_format(ab, "resp=%u fan_type=%u fan_info=", > > + response, friar- > >hdr.type); > > +#define INCOMPLETE "(incomplete)" > > + audit_log_n_hex(ab, INCOMPLETE, sizeof(INCOMPLETE)); > > + audit_log_end(ab); > > + } > > return; > > } > > - audit_log(audit_context(), GFP_KERNEL, AUDIT_FANOTIFY, > > - "resp=%u fan_type=%u fan_info=%u", > > - response, friar->hdr.type, friar->audit_rule); > > + ab = audit_log_start(ctx, GFP_KERNEL, AUDIT_FANOTIFY); > > + if (ab) { > > + audit_log_format(ab, "resp=%u fan_type=%u fan_info=", > > + response, friar->hdr.type); > > + audit_log_n_hex(ab, (char *)&friar->audit_rule, > > + sizeof(friar->audit_rule)); > > + audit_log_end(ab); > > + > > + } > > } > > c -= friar->hdr.len; > > ib += friar->hdr.len; > > > > - RGB -- Richard Guy Briggs <rgb@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
WARNING: multiple messages have this Message-ID (diff)
From: Richard Guy Briggs <rgb@redhat.com> To: Steve Grubb <sgrubb@redhat.com> Cc: Jan Kara <jack@suse.cz>, Amir Goldstein <amir73il@gmail.com>, LKML <linux-kernel@vger.kernel.org>, Linux-Audit Mailing List <linux-audit@redhat.com>, linux-fsdevel@vger.kernel.org, Eric Paris <eparis@parisplace.org> Subject: Re: [PATCH v4 4/4] fanotify, audit: deliver fan_info as a hex-encoded string Date: Wed, 10 Aug 2022 22:23:49 -0400 [thread overview] Message-ID: <YvRoNSL0snBY87/b@madcap2.tricolour.ca> (raw) In-Reply-To: <5623945.DvuYhMxLoT@x2> On 2022-08-10 15:15, Steve Grubb wrote: > Hell Richard, That's quite an introduction! ;-) > On Tuesday, August 9, 2022 1:22:55 PM EDT Richard Guy Briggs wrote: > > Currently the only type of fanotify info that is defined is an audit > > rule number, but convert it to hex encoding to future-proof the field. > > > > Sample record: > > type=FANOTIFY msg=audit(1659730979.839:284): resp=1 fan_type=0 > > fan_info=3F > > I compiled a new kernel and run old user space on this. The above event is > exactly what I see in my audit logs. Why the fan_info=3F? I really would have > expected 0. What if the actual rule number was 63? I think this will work > better to leave everything 0 with old user space. Well, if it is to be consistently hex encoded, that corresponds to "?" if it is to be interpreted as a string. Since the fan_type is 0, fan_info would be invalid, so a value of 0 would be entirely reasonable, hex encoded to fan_info=00. It could also be hex encoded to the string "(none)". If you wanted "0" for fan_type=FAN_RESPONSE_INFO_AUDIT_RULE, that would be fan_info=30 if it were interpreted as a string, or arguably 3F for an integer of rule (decimal) 63. Ultimately, fan_type should determine how fan_info's hex encoded value should be interpreted. But ultimately, the point of this patch is to hex encode the fan_info field value. > -Steve > > > Suggested-by: Paul Moore <paul@paul-moore.com> > > Signed-off-by: Richard Guy Briggs <rgb@redhat.com> > > --- > > kernel/auditsc.c | 28 +++++++++++++++++++++------- > > 1 file changed, 21 insertions(+), 7 deletions(-) > > > > diff --git a/kernel/auditsc.c b/kernel/auditsc.c > > index f000fec52360..0f747015c577 100644 > > --- a/kernel/auditsc.c > > +++ b/kernel/auditsc.c > > @@ -2908,22 +2908,36 @@ void __audit_fanotify(u32 response, size_t len, > > char *buf) > > > > if (!(len && buf)) { > > audit_log(audit_context(), GFP_KERNEL, AUDIT_FANOTIFY, > > - "resp=%u fan_type=0 fan_info=?", response); > > + "resp=%u fan_type=0 fan_info=3F", response); /* "?" */ > > return; > > } > > while (c >= sizeof(struct fanotify_response_info_header)) { > > + struct audit_context *ctx = audit_context(); > > + struct audit_buffer *ab; > > + > > friar = (struct fanotify_response_info_audit_rule *)buf; > > 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); > > + ab = audit_log_start(ctx, GFP_KERNEL, AUDIT_FANOTIFY); > > + if (ab) { > > + audit_log_format(ab, "resp=%u fan_type=%u fan_info=", > > + response, friar- > >hdr.type); > > +#define INCOMPLETE "(incomplete)" > > + audit_log_n_hex(ab, INCOMPLETE, sizeof(INCOMPLETE)); > > + audit_log_end(ab); > > + } > > return; > > } > > - audit_log(audit_context(), GFP_KERNEL, AUDIT_FANOTIFY, > > - "resp=%u fan_type=%u fan_info=%u", > > - response, friar->hdr.type, friar->audit_rule); > > + ab = audit_log_start(ctx, GFP_KERNEL, AUDIT_FANOTIFY); > > + if (ab) { > > + audit_log_format(ab, "resp=%u fan_type=%u fan_info=", > > + response, friar->hdr.type); > > + audit_log_n_hex(ab, (char *)&friar->audit_rule, > > + sizeof(friar->audit_rule)); > > + audit_log_end(ab); > > + > > + } > > } > > c -= friar->hdr.len; > > ib += friar->hdr.len; > > > > - RGB -- Richard Guy Briggs <rgb@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 -- Linux-audit mailing list Linux-audit@redhat.com https://listman.redhat.com/mailman/listinfo/linux-audit
next prev parent reply other threads:[~2022-08-11 2:24 UTC|newest] Thread overview: 91+ messages / expand[flat|nested] mbox.gz Atom feed top 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 ` 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 ` Richard Guy Briggs [this message] 2022-08-11 2:23 ` 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=YvRoNSL0snBY87/b@madcap2.tricolour.ca \ --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.