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 us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 0E85FECAAD4 for ; Thu, 1 Sep 2022 00:32:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1661992358; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post; bh=TfGibPGIl3J1xAcRs1hk8yva8Qfq3yn2hptID+nY0Og=; b=UvhtPabglK4NPZtZE/OyjJRBD2HnN9QWt8j8gRqmkQ0oXIQlg22S3pWLS8hy6j+YhQEgU3 dnzj+UQMdPHB1hZbHTonYKkheCJHUq/sDYDj5dyaR5U/wdf52iE3y7ztrmUXM4O2i/77Ie 30/jV7K0o9iJlM1nX4EubF6Uf5yrfws= Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-594-xQuqYFsOMGyEaYfIxVRjAA-1; Wed, 31 Aug 2022 20:32:35 -0400 X-MC-Unique: xQuqYFsOMGyEaYfIxVRjAA-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.rdu2.redhat.com [10.11.54.8]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 9B00C3C0F368; Thu, 1 Sep 2022 00:32:34 +0000 (UTC) Received: from mm-prod-listman-01.mail-001.prod.us-east-1.aws.redhat.com (unknown [10.30.29.100]) by smtp.corp.redhat.com (Postfix) with ESMTP id BDDD6C15BB3; Thu, 1 Sep 2022 00:32:33 +0000 (UTC) Received: from mm-prod-listman-01.mail-001.prod.us-east-1.aws.redhat.com (localhost [IPv6:::1]) by mm-prod-listman-01.mail-001.prod.us-east-1.aws.redhat.com (Postfix) with ESMTP id A2DDB1946A4A; Thu, 1 Sep 2022 00:32:33 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx10.intmail.prod.int.rdu2.redhat.com [10.11.54.10]) by mm-prod-listman-01.mail-001.prod.us-east-1.aws.redhat.com (Postfix) with ESMTP id E903F1946A40 for ; Wed, 31 Aug 2022 23:55:39 +0000 (UTC) Received: by smtp.corp.redhat.com (Postfix) id 91B8F40315A; Wed, 31 Aug 2022 23:55:39 +0000 (UTC) Received: from x2.localnet (unknown [10.22.32.74]) by smtp.corp.redhat.com (Postfix) with ESMTPS id CE598492C3B; Wed, 31 Aug 2022 23:55:38 +0000 (UTC) From: Steve Grubb To: Richard Guy Briggs Subject: Re: [PATCH v4 3/4] fanotify, audit: Allow audit to use the full permission event response Date: Wed, 31 Aug 2022 19:55:38 -0400 Message-ID: <5600292.DvuYhMxLoT@x2> Organization: Red Hat In-Reply-To: References: <12063373.O9o76ZdvQC@x2> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.85 on 10.11.54.10 X-BeenThere: linux-audit@redhat.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux Audit Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Jan Kara , Amir Goldstein , LKML , Linux-Audit Mailing List , linux-fsdevel@vger.kernel.org, Eric Paris Errors-To: linux-audit-bounces@redhat.com Sender: "Linux-audit" X-Scanned-By: MIMEDefang 2.85 on 10.11.54.8 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit On Wednesday, August 31, 2022 6:19:40 PM EDT Richard Guy Briggs wrote: > On 2022-08-31 17:25, Steve Grubb wrote: > > On Wednesday, August 31, 2022 5:07:25 PM EDT Richard Guy Briggs wrote: > > > > > 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 > > > > > #include > > > > > #include // struct open_how > > > > > +#include > > > > > > > > > > #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? > > > > I don't see a reason for sending more than one header. What is more > > probable is the need to send additional data in that header. I was > > thinking of maybe bit mapping it in the rule number. But I'd suggest > > padding the struct just in case it needs expanding some day. > > This doesn't exactly answer my question about multiple rules > contributing to one decision. I don't forsee that. > The need for more as yet undefined information sounds like a good reason > to define a new header if that happens. It's much better to pad the struct so that the size doesn't change. > At this point, is it reasonable to throw an error if more than one RULE > header appears in a message? It is a write syscall. I'd silently discard everything else and document that in the man pages. But the fanotify maintainers should really weigh in on this. > The way I had coded this last patchset was to allow for more than one RULE > header and each one would get its own record in the event. I do not forsee a need for this. > How many rules total are likely to exist? Could be a thousand. But I already know some missing information we'd like to return to user space in an audit event, so the bit mapping on the rule number might happen. I'd suggest padding one u32 for future use. -Steve -- Linux-audit mailing list Linux-audit@redhat.com https://listman.redhat.com/mailman/listinfo/linux-audit