Received: by 2002:a05:6358:a55:b0:ec:fcf4:3ecf with SMTP id 21csp3090636rwb; Fri, 20 Jan 2023 11:03:29 -0800 (PST) X-Google-Smtp-Source: AMrXdXvTAbfYiwJFcI4U8asClZSTGkt3loaOIxCllqSlMO8NFgjy1SaeE0BLzsqhaERrmVP9meSS X-Received: by 2002:a17:902:ab50:b0:189:bc50:b93b with SMTP id ij16-20020a170902ab5000b00189bc50b93bmr14588076plb.3.1674241409245; Fri, 20 Jan 2023 11:03:29 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1674241409; cv=none; d=google.com; s=arc-20160816; b=VRC+2fr+0DUt3ygaLtolVFYxNPe1PVUVKqYOUFrTxzaw5IxpIYHtk0pUkd1H30AHv7 UFIzv01qCNhdR6feqlHNvXhf+L8PYryE/Fn3WX4vsMWEJQ9Fpa++vU40ra40aVI1FpKq LZX4UlvTWh+HWD2anP3fBYHDwMMVnUogSaas3KgxgS4PgIG1Iz6hg17uHutiBBc2vVCO 6xRz7kKmAkug9aEBKBIdkrJ9YOxxK4MRqZDYami1gDTARk4BxE3aUZYi4M5eGgZAths2 iSXAIxs1Pj5NDtQ5LXTA53+TTi7hJXesoJ1mGUJBF+4iPx7xqnAyWNYBBqSGoAro1Fpc wJmw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=FPfy+reM6AKfPj+P9Rafnu4Ibypa0LESref2+wODD18=; b=iHXJvWIg8qhapdQwM90A4Z4lLpI77fvHwINxPydFM28m7D9y5BI/vHj4eotXXAoqI2 E5LuaaMdG/tn70K1j5fRMq4Qjv0G0P9UYnzMaPXM8D/MApVMurXJZ20Ko78f/8Kq4aIJ oSuGR3IrBfNOqsOByCtZLufhyT661PYboq1Yt65ztH9xrQQu28ceFZnAPpcFQHLMQ93J g8NwHQUEHR/xFsIWnZDKMslRp01tSl5kEpBRAmLUcq5Hj8R7BRfYfFYHo5fa/9jHz4rY tSKBX4mzs3tja/BoI9PrBYqkTmexdSyGFmBKRo5zl+Bx4ga1lypxSYmV4FoiULYeNBLN Opug== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@paul-moore.com header.s=google header.b=Qfzg23MV; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=paul-moore.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id t21-20020a170902e1d500b00194a2575c84si2099524pla.596.2023.01.20.11.03.23; Fri, 20 Jan 2023 11:03:29 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@paul-moore.com header.s=google header.b=Qfzg23MV; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=paul-moore.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229471AbjATSww (ORCPT + 50 others); Fri, 20 Jan 2023 13:52:52 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57236 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229379AbjATSwu (ORCPT ); Fri, 20 Jan 2023 13:52:50 -0500 Received: from mail-pg1-x52a.google.com (mail-pg1-x52a.google.com [IPv6:2607:f8b0:4864:20::52a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A87E54ABEB for ; Fri, 20 Jan 2023 10:52:49 -0800 (PST) Received: by mail-pg1-x52a.google.com with SMTP id s67so4831058pgs.3 for ; Fri, 20 Jan 2023 10:52:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paul-moore.com; s=google; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=FPfy+reM6AKfPj+P9Rafnu4Ibypa0LESref2+wODD18=; b=Qfzg23MVKgyve2XBzoW31NlYobIFWVOHHhwhcxalDk919SMGtf0YJaHtxZMf1d6Ji3 4kmpjikIrJlw3ahROk+iqBz3xm4E5b8+wOCe8Y2OD9DuMHBpV0bPHaDe6nWFE4ZUt+RE IbjV9G8LXvyOHLU3mO5csO9PXC5pYbXfGAgBgGh1ZijJsBfuNsS0xomY2QZuLqi4xJFI 69aQdSdznYDRBBSGBz64fiG/Tth12IfyMbr0gpjdtopykXPMh5FejbsR1l9SumXbwwVj i4yXq2VEpOfK7TunocUMGhyjljpG5oQLInecNKf09hsbPsmErfOtYsue28Ccdw8rX3Hj ubsg== 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=FPfy+reM6AKfPj+P9Rafnu4Ibypa0LESref2+wODD18=; b=DMl/4Gq/VH6CPiX5qeA3iGEPgjMT9dG6fICtjrDE1wqasRiupMkVm3tHEr3I/dQFH9 5CDUkAKXBJYqZjaY/AkqrFfKgye39uKNwX0rRULv7aSpR367hlgPbw2J22CNUSP7v/8A 5b/XSI8o+32bpaVZzYGpr8EwsERUxDTBQupsV7WtPzya3IohQ6Gz/dKsKq22kYxbnIiE kI1CIU2Xaw2zZTOD1lLHmQg3voGQf5dOquwdrWRL3lWPG/X8KNIwlB6FDNwICDNLCPOo MOVkaeZnocyQtWO1PoaSOM9p5oSfYbF+bkBUDU7D+AircfQPKXKbEvlq2Rpo2YOMQuxR gRbA== X-Gm-Message-State: AFqh2kqCLQe/oB4hymlPjmyIRBOErVGZVuHIObhkN6un2OFamCmjBBY6 QOCa666K3h2kCtsqNiYO7p0RHVG9oOAkBw5+bTtA X-Received: by 2002:a05:6a00:f07:b0:577:62a8:f7a1 with SMTP id cr7-20020a056a000f0700b0057762a8f7a1mr1561601pfb.2.1674240769040; Fri, 20 Jan 2023 10:52:49 -0800 (PST) MIME-Version: 1.0 References: <82aba376bfbb9927ab7146e8e2dee8d844a31dc2.1673989212.git.rgb@redhat.com> <5680172.DvuYhMxLoT@x2> In-Reply-To: <5680172.DvuYhMxLoT@x2> From: Paul Moore Date: Fri, 20 Jan 2023 13:52:37 -0500 Message-ID: Subject: Re: [PATCH v6 3/3] fanotify,audit: Allow audit to use the full permission event response To: Steve Grubb Cc: Linux-Audit Mailing List , LKML , linux-fsdevel@vger.kernel.org, linux-api@vger.kernel.org, Richard Guy Briggs , Eric Paris , Jan Kara , Amir Goldstein Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jan 18, 2023 at 1:34 PM Steve Grubb wrote: > > Hello Richard, > > I built a new kernel and tested this with old and new user space. It is > working as advertised. The only thing I'm wondering about is why we have 3F > as the default value when no additional info was sent? Would it be better to > just make it 0? ... > On Tuesday, January 17, 2023 4:14:07 PM EST Richard Guy Briggs wrote: > > diff --git a/kernel/auditsc.c b/kernel/auditsc.c > > index d1fb821de104..3133c4175c15 100644 > > --- a/kernel/auditsc.c > > +++ b/kernel/auditsc.c > > @@ -2877,10 +2878,19 @@ 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); > > + /* {subj,obj}_trust values are {0,1,2}: no,yes,unknown */ > > + 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); > > + return; > > + } (I'm working under the assumption that the "fan_info=3F" in the record above is what Steve was referring to in his comment.) I vaguely recall Richard commenting on this in the past, although maybe not ... my thought is that the "3F" is simply the hex encoded "?" character in ASCII ('man 7 ascii' is your friend). I suppose the question is what to do in the FAN_RESPONSE_INFO_NONE case. Historically when we had a missing field we would follow the "field=?" pattern, but I don't recall doing that for a field which was potentially hex encoded, is there an existing case where we use "?" for a field that is hex encoded? If so, we can swap out the "3F" for a more obvious "?". However, another option might be to simply output the current AUDIT_FANOTIFY record format in the FAN_RESPONSE_INFO_NONE case, e.g. only "resp=%u". This is a little against the usual guidance of "fields should not disappear from a record", but considering that userspace will always need to support the original resp-only format for compatibility reasons this may be an option. -- paul-moore.com