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 AD61FECAAD4 for ; Wed, 31 Aug 2022 22:20:02 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232427AbiHaWUA (ORCPT ); Wed, 31 Aug 2022 18:20:00 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46786 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232286AbiHaWTz (ORCPT ); Wed, 31 Aug 2022 18:19:55 -0400 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2281564DF for ; Wed, 31 Aug 2022 15:19:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1661984390; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=rKIZ2WTLtQjucL02x9Nc2ffupTcwbvlTRvUJuSYdwkI=; b=VTk5emfgK/Ef0UOFdo3O5WFqlDZdLk/ULvDTWTce37X5dvl6YlYFToNA2BAsTjwJY0+i2K 3adyocRV1LgDKScdc1CNknCrNqy+JAgKFovcICuCZhji+6K/MKKVh9Ae4UsEMkt19Nl5xJ ydxNcpFF/ZJqN92eW1vrtPv6HNH3YDc= 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-67-uaDSlbJCOzS39kahpTWe3g-1; Wed, 31 Aug 2022 18:19:44 -0400 X-MC-Unique: uaDSlbJCOzS39kahpTWe3g-1 Received: from smtp.corp.redhat.com (int-mx09.intmail.prod.int.rdu2.redhat.com [10.11.54.9]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 163F038164CD; Wed, 31 Aug 2022 22:19:44 +0000 (UTC) Received: from madcap2.tricolour.ca (unknown [10.22.48.5]) by smtp.corp.redhat.com (Postfix) with ESMTPS id CDF0B492C3B; Wed, 31 Aug 2022 22:19:42 +0000 (UTC) Date: Wed, 31 Aug 2022 18:19:40 -0400 From: Richard Guy Briggs To: Steve Grubb Cc: Paul Moore , Linux-Audit Mailing List , LKML , linux-fsdevel@vger.kernel.org, Eric Paris , Jan Kara , Amir Goldstein Subject: Re: [PATCH v4 3/4] fanotify,audit: Allow audit to use the full permission event response Message-ID: References: <12063373.O9o76ZdvQC@x2> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <12063373.O9o76ZdvQC@x2> X-Scanned-By: MIMEDefang 2.85 on 10.11.54.9 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. The need for more as yet undefined information sounds like a good reason to define a new header if that happens. At this point, is it reasonable to throw an error if more than one RULE header appears in a message? 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. How many rules total are likely to exist? > -Steev - RGB -- Richard Guy Briggs 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