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: Fri, 19 Aug 2022 17:42:53 -0400 [thread overview]
Message-ID: <YwAD3SmDUeKc+5ht@madcap2.tricolour.ca> (raw)
In-Reply-To: <4767361.31r3eYUQgx@x2>
On 2022-08-16 09:37, Steve Grubb wrote:
> Hello Richard,
>
> Although I have it working, I have some comments below that might improve
> things.
>
> 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
> >
> > 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));
>
> One thing to point out, the structure has a member audit_rule. It is
> probably better to call it rule_number. This is because it has nothing to
> do with any actual audit rule. It is a rule number meant to be recorded by
> the audit system.
>
> Also, that member is a __u32 type. Hex encoding that directly gives back a
> __u32 when decoded - which is a bit unexpected since everything else is
> strings. It would be better to convert the u32 to a base 10 string and then
> hex encode that. A buffer of 12 bytes should be sufficient.
Sure, these seem reasonable.
> Thanks,
> -Steve
>
> > + 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
next prev parent reply other threads:[~2022-08-19 21:43 UTC|newest]
Thread overview: 44+ 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 ` [PATCH v4 1/4] fanotify: Ensure consistent variable type for response 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-10 6:22 ` Amir Goldstein
2022-08-19 11:24 ` Jan Kara
2022-08-10 14:28 ` kernel test robot
2022-08-19 16:25 ` Richard Guy Briggs
2022-08-19 17:17 ` Nick Desaulniers
2022-08-19 21:45 ` Richard Guy Briggs
2022-08-12 0:23 ` Matthew Bobrowski
2022-08-19 11:16 ` 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-10 20:32 ` kernel test robot
2022-08-16 0:22 ` Paul Moore
2022-08-31 21:07 ` Richard Guy Briggs
2022-08-31 21:25 ` Steve Grubb
2022-08-31 22:19 ` Richard Guy Briggs
2022-08-31 23:55 ` Steve Grubb
2022-09-01 1:47 ` Paul Moore
2022-09-01 7:51 ` Jan Kara
2022-09-01 18:31 ` Paul Moore
2022-09-07 18:43 ` Richard Guy Briggs
2022-09-07 20:11 ` Steve Grubb
2022-09-07 20:23 ` Paul Moore
2022-09-08 21:14 ` Steve Grubb
2022-09-08 21:22 ` Paul Moore
2022-09-09 2:20 ` Steve Grubb
2022-09-09 2:41 ` Richard Guy Briggs
2022-09-09 3:25 ` Paul Moore
2022-09-09 4:03 ` Steve Grubb
2022-09-09 11:09 ` Jan Kara
2022-09-09 14:22 ` Steve Grubb
2022-09-09 14:38 ` Richard Guy Briggs
2022-09-09 14:55 ` Steve Grubb
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-10 19:15 ` Steve Grubb
2022-08-11 2:23 ` Richard Guy Briggs
2022-08-15 21:15 ` Steve Grubb
2022-08-16 0:31 ` Paul Moore
2022-08-16 13:37 ` Steve Grubb
2022-08-19 21:42 ` Richard Guy Briggs [this message]
2022-08-10 5:21 ` [PATCH v4 0/4] fanotify: Allow user space to pass back additional audit info 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=YwAD3SmDUeKc+5ht@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: 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
all inboxes | Powered by JetHome®