From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 31C4BC4332F for ; Tue, 20 Dec 2022 23:32:04 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234270AbiLTXb5 (ORCPT ); Tue, 20 Dec 2022 18:31:57 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36162 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234178AbiLTXbz (ORCPT ); Tue, 20 Dec 2022 18:31:55 -0500 Received: from mail-pl1-x632.google.com (mail-pl1-x632.google.com [IPv6:2607:f8b0:4864:20::632]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 039D41FCCE for ; Tue, 20 Dec 2022 15:31:55 -0800 (PST) Received: by mail-pl1-x632.google.com with SMTP id d3so13814266plr.10 for ; Tue, 20 Dec 2022 15:31:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paul-moore-com.20210112.gappssmtp.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=aNvwx1f2Fh9J2I3ow+8tnVvZQ5g3r2kgzwtdsL7kVXU=; b=oWguqbs4iid3zUKQbiLJ8Pywmc14jtVoWF+gl/hsbMUrxll/0vAhbU7/XcJo4y1XFr 3YaGiddbcxU9ha/qQDrQymW9M461agfVdQFv0sKy86Z/X8AWCI/ut/XnkdNyce2mirg/ s3I9gvTQMuS4Ksat8ZW4edrFpu8ADFEyvYHoUFzLIiiyheCXkb7/nz2+QB+vjTo4cJTc C/uhH9B8TfAFznkvg27CgaUj0JzDhfMGkF9yPcSqYGm7ugypHmdKxTg3rwCEvAHZYRGO 2ZLHg8poJlUUrVKsJW2kaSKSgDeT0M2fKm4oRhn2yoWrjaqSIVCHE1wqGRJMvBxTV8sU MCqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=aNvwx1f2Fh9J2I3ow+8tnVvZQ5g3r2kgzwtdsL7kVXU=; b=tPtJutSkpAU3omUiCELVh5QImMekr8hC1B2mha9+oXyTQ0j2TPLNBYlmyQ7aPguN0x nNJz3fa049qUjV+c4s16rVIXEU04g9D9WKgpy78iUcLKtwn4VyVaQffuIIkpOw5CvtUX zuTFOxxYVi/7V3YeXsYfScMkPECnCJaT88FQAMK5lksuxJd+HcD5S+g6FgC918ja2AMG YCj8jYIN9gXu5nvxWRP7qVelW1yOQXFl4hLpXq4KpoOLmBFlnhXbz+r4Id1Ega1mojGK l3c5DCPkFfojBpPWijGiHrqSsgWilvAqdIR3PQWbyh72MSifL+nrP16IvklVdfxkI913 qHbQ== X-Gm-Message-State: AFqh2kp3VhXlp7x/mlOrfRuOQzRWdIAivX5v/VAStCsTXqrOcMw45eAn H2SlQFUUGS/IX8NMpwPUlWZKN3zcaOysfO1iHKF/Zvuz2igdTZg= X-Google-Smtp-Source: AMrXdXvBpq9QnNE8Y4rIAjEUbNiQzoI2AuEU1LAlXJlJ3cXz5EoaZFQzreLaQrZb/OX0AgiBktAoy1GSdjW3Et+zoLw= X-Received: by 2002:a17:90a:6481:b0:221:5597:5de7 with SMTP id h1-20020a17090a648100b0022155975de7mr2001291pjj.147.1671579114449; Tue, 20 Dec 2022 15:31:54 -0800 (PST) MIME-Version: 1.0 References: <79fcf72ea442eeede53ed5e6de567f8df8ef7d83.1670606054.git.rgb@redhat.com> In-Reply-To: <79fcf72ea442eeede53ed5e6de567f8df8ef7d83.1670606054.git.rgb@redhat.com> From: Paul Moore Date: Tue, 20 Dec 2022 18:31:43 -0500 Message-ID: Subject: Re: [PATCH v5 3/3] fanotify,audit: Allow audit to use the full permission event response To: Richard Guy Briggs Cc: Linux-Audit Mailing List , LKML , linux-fsdevel@vger.kernel.org, linux-api@vger.kernel.org, Eric Paris , Steve Grubb , Jan Kara , Amir Goldstein Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-api@vger.kernel.org On Mon, Dec 12, 2022 at 9:06 AM Richard Guy Briggs wrote: > > This patch passes the full response 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. > > 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. > Hex encoding suggested by Paul Moore . > > Sample records: > type=FANOTIFY msg=audit(1600385147.372:590): resp=2 fan_type=1 fan_info=3137 subj_trust=3 obj_trust=5 > type=FANOTIFY msg=audit(1659730979.839:284): resp=1 fan_type=0 fan_info=3F subj_trust=2 obj_trust=2 > > Suggested-by: Steve Grubb > Link: https://lore.kernel.org/r/3075502.aeNJFYEL58@x2 > Signed-off-by: Richard Guy Briggs > --- > fs/notify/fanotify/fanotify.c | 3 ++- > include/linux/audit.h | 9 +++++---- > kernel/auditsc.c | 25 ++++++++++++++++++++++--- > 3 files changed, 29 insertions(+), 8 deletions(-) ... > diff --git a/kernel/auditsc.c b/kernel/auditsc.c > index d1fb821de104..8d523066d81f 100644 > --- a/kernel/auditsc.c > +++ b/kernel/auditsc.c > @@ -64,6 +64,7 @@ > #include > #include > #include // struct open_how > +#include > > #include "audit.h" > > @@ -2877,10 +2878,28 @@ void __audit_log_kern_module(char *name) > context->type = AUDIT_KERN_MODULE; > } > > -void __audit_fanotify(u32 response) > +void __audit_fanotify(u32 response, struct fanotify_response_info_audit_rule *friar) > { > - audit_log(audit_context(), GFP_KERNEL, > - AUDIT_FANOTIFY, "resp=%u", response); > + struct audit_context *ctx = audit_context(); > + struct audit_buffer *ab; > + char numbuf[12]; > + > + if (friar->hdr.type == FAN_RESPONSE_INFO_NONE) { > + audit_log(audit_context(), GFP_KERNEL, AUDIT_FANOTIFY, > + "resp=%u fan_type=%u fan_info=3F subj_trust=2 obj_trust=2", > + response, FAN_RESPONSE_INFO_NONE); The fan_info, subj_trust, and obj_trust constant values used here are awfully magic-numbery and not the usual sentinel values one might expect for a "none" operation, e.g. zeros/INT_MAX/etc. I believe a comment here explaining the values would be a good idea. > + return; > + } > + 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); > + snprintf(numbuf, sizeof(numbuf), "%u", friar->rule_number); > + audit_log_n_hex(ab, numbuf, sizeof(numbuf)); It looks like the kernel's printf format string parsing supports %X so why not just use that for now, we can always complicate it later if needed. It would probably also remove the need for the @ab, @numbuf, and @ctx variables. For example: audit_log(audit_context(), GFP_KERNEL, AUDIT_FANOTIFY, "resp=%u fan_type=%u fan_info=%X subj_trust=%u obj_trust=%u", response, friar->hdr.type, friar->rule_number, friar->subj_trust, friar->obj_trust); Am I missing something? > + audit_log_format(ab, " subj_trust=%u obj_trust=%u", > + friar->subj_trust, friar->obj_trust); > + audit_log_end(ab); > + } > } > > void __audit_tk_injoffset(struct timespec64 offset) > -- > 2.27.0 -- paul-moore.com