[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHC9VhQYDsjx2QVRqU8NUr2p4MsWi7DKEFXMk4MvVyEbv4niHQ@mail.gmail.com>
Date: Mon, 15 Aug 2022 20:31:09 -0400
From: Paul Moore <paul@...l-moore.com>
To: Richard Guy Briggs <rgb@...hat.com>
Cc: Linux-Audit Mailing List <linux-audit@...hat.com>,
LKML <linux-kernel@...r.kernel.org>,
linux-fsdevel@...r.kernel.org, Eric Paris <eparis@...isplace.org>,
Steve Grubb <sgrubb@...hat.com>, Jan Kara <jack@...e.cz>,
Amir Goldstein <amir73il@...il.com>
Subject: Re: [PATCH v4 4/4] fanotify,audit: deliver fan_info as a hex-encoded string
On Tue, Aug 9, 2022 at 1:23 PM Richard Guy Briggs <rgb@...hat.com> 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@...l-moore.com>
> Signed-off-by: Richard Guy Briggs <rgb@...hat.com>
> ---
> kernel/auditsc.c | 28 +++++++++++++++++++++-------
> 1 file changed, 21 insertions(+), 7 deletions(-)
This needs to be squashed with patch 3/4; it's a user visible change
so we don't want someone backporting 3/4 without 4/4, especially when
it is part of the same patchset.
> 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); /* "?" */
Please drop the trailing comment, it's not necessary and it makes the
code messier.
> 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));
Is the distinction between "?" and "(incomplete)" really that
important? I'm not going to go digging through all of the
audit_log_format() callers to check, but I believe there is precedence
for using "?" not only for when a value is missing, but when it is
bogus as well.
If we are really going to use "(incomplete)" here, let's do a better
job than defining a macro mid-function and only using it in one other
place - the line immediately below the definition. This is both ugly
and a little silly (especially when one considers that the macro name
is almost exactly the same as the string it replaces. If we must use
"(incomplete)" here, just ditch the macro; any conceptual arguments
about macros vs literals is largely rendered moot since there is only
one user.
> + 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;
> --
> 2.27.0
--
paul-moore.com
Powered by blists - more mailing lists