Received: by 2002:a6b:500f:0:0:0:0:0 with SMTP id e15csp1615138iob; Fri, 29 Apr 2022 09:01:54 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwnskYQzJYlY89WNtcN8QaSwWVYKCTswRaRZAEHOjyjV1W9WYCCepmz8MxBE2d/NWuEZj7m X-Received: by 2002:a2e:8789:0:b0:24f:124c:864a with SMTP id n9-20020a2e8789000000b0024f124c864amr16596880lji.164.1651248114582; Fri, 29 Apr 2022 09:01:54 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1651248114; cv=none; d=google.com; s=arc-20160816; b=z/Cfiivufk0CjAzAVMIa2z9pnS+cNddHl41VRvv8cdU+XMuRCXApitXgmHDOWX3/OH OoBzeVmhMcBjFJAShIpet6uEcVmmDoTDk+/0r+o8+DpscqVMrvya7Ek1YLP8MMHC1pjW d+CGwLSjRN4JxtWkIs4NoJYMZlBLxi121stvpJJMyumS9+fvFBW4BZ/nWFBYZdlxfDCt X8cVcVadd3Q2QrxNEs1h3++XOLZsoD752pnpyWKNLMEci6Kj1ImjLS368ufQ/sCu9cdY xv9ci/+hpbKZTfSY20GQwSzuFPZuca/gJ9IEsmJ99ST3dz05wzCacK4ErR72JLiQZOEP ns7Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=dTvROQQ49sVjYocOeNNYIv0FPtF4+TnxaG7UpbtPvKI=; b=Dh5hePDducJBsRBsn4JRzBgRtkMj4crQv12+aUdsRdgv1PgYD9h0aeiecNux7D2liT ZmOisv3ZBL0mJajHGC8nSpe/MaYh3gz/Fb9xzlra78xzATyOfaE1gUQLGgtL+Y3e4HeW MqfdaJ15IqROl/eOcodFQXk38ub4jP4YCyaooVK5rwr1bNaqzwmREPW/QXo+k5vDRE7K KeKkthaKqNwknPtggZEvnY6Z4VaOvtPczKEOnT/j6InIvnjPQ6BVfrJFT7PrVpwekUlS GPzhegrMe033qx2lEQ3cUvHWdNqa9XndNonO3kZZvfZuiI3R/w/lc4MDrtkxMChhjKGt JaQA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=EcTjT064; 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=redhat.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id b12-20020a056512304c00b00471c6f5e868si7503401lfb.582.2022.04.29.09.01.24; Fri, 29 Apr 2022 09:01:54 -0700 (PDT) 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=@redhat.com header.s=mimecast20190719 header.b=EcTjT064; 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=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1353051AbiD2Asq (ORCPT + 99 others); Thu, 28 Apr 2022 20:48:46 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39106 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1353142AbiD2Aso (ORCPT ); Thu, 28 Apr 2022 20:48:44 -0400 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 82D6A8879D for ; Thu, 28 Apr 2022 17:45:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1651193125; 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: content-transfer-encoding:content-transfer-encoding; bh=dTvROQQ49sVjYocOeNNYIv0FPtF4+TnxaG7UpbtPvKI=; b=EcTjT064BlXb+HVMxnvi2zV6oQWmIs2n5lcvS9ToigdfDmFSap3Geef7eOEhiBeAgFWm2P iqmjqLlEQQ8vqmxRlE860YrcstRidKUHBYsskKXInOgk4EfPy58aVhLFXWSkQofzO/KKfI 9ktCXFsaJZgBxWxLkuP1hfDIZ3N+YJ4= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-410-tfhRk1WJMIivilljplxVuQ-1; Thu, 28 Apr 2022 20:45:22 -0400 X-MC-Unique: tfhRk1WJMIivilljplxVuQ-1 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.rdu2.redhat.com [10.11.54.5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 7D7DE185A7A4; Fri, 29 Apr 2022 00:45:21 +0000 (UTC) Received: from madcap2.tricolour.com (ovpn-0-8.rdu2.redhat.com [10.22.0.8]) by smtp.corp.redhat.com (Postfix) with ESMTP id B78A19E8F; Fri, 29 Apr 2022 00:44:54 +0000 (UTC) From: Richard Guy Briggs To: Linux-Audit Mailing List , LKML , linux-fsdevel@vger.kernel.org Cc: Paul Moore , Eric Paris , Steve Grubb , Richard Guy Briggs , Jan Kara Subject: [PATCH v2 0/3] fanotify: Allow user space to pass back additional audit info Date: Thu, 28 Apr 2022 20:44:33 -0400 Message-Id: MIME-Version: 1.0 Content-type: text/plain Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.79 on 10.11.54.5 X-Spam-Status: No, score=-3.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_LOW, SPF_HELO_NONE,SPF_NONE 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 The Fanotify API can be used for access control by requesting permission event notification. The user space tooling that uses it may have a complicated policy that inherently contains additional context for the decision. If this information were available in the audit trail, policy writers can close the loop on debugging policy. Also, if this additional information were available, it would enable the creation of tools that can suggest changes to the policy similar to how audit2allow can help refine labeled security. This patch defines 2 additional fields within the response structure returned from user space on a permission event. The first field is 16 bits for the context type. The context type will describe what the meaning is of the second field. The audit system will separate the pieces and log them individually. The audit function was updated to log the additional information in the AUDIT_FANOTIFY record. The following is an example of the new record format: type=FANOTIFY msg=audit(1600385147.372:590): resp=2 fan_type=1 fan_ctx=17 changelog: v1: - first version by Steve Grubb Link: https://lore.kernel.org/r/2042449.irdbgypaU6@x2 v2: - enhancements suggested by Jan Kara - 1/3 change %d to %u in pr_debug - 2/3 change response from __u32 to __u16 - mod struct fanotify_response and fanotify_perm_event add extra_info_type, extra_info_buf - extra_info_buf size max FANOTIFY_MAX_RESPONSE_EXTRA_LEN, add struct fanotify_response_audit_rule - extend debug statements - remove unneeded macros - [internal] change interface to finish_permission_event() and process_access_response() - 3/3 update format of extra information - [internal] change interface to audit_fanotify() - change ctx_type= to fan_type= Link: https://lore.kernel.org/r/cover.1651174324.git.rgb@redhat.com Richard Guy Briggs (3): fanotify: Ensure consistent variable type for response fanotify: define struct members to hold response decision context fanotify: Allow audit to use the full permission event response fs/notify/fanotify/fanotify.c | 5 ++- fs/notify/fanotify/fanotify.h | 4 +- fs/notify/fanotify/fanotify_user.c | 59 ++++++++++++++++++++---------- include/linux/audit.h | 8 ++-- include/linux/fanotify.h | 3 ++ include/uapi/linux/fanotify.h | 27 +++++++++++++- kernel/auditsc.c | 18 +++++++-- 7 files changed, 94 insertions(+), 30 deletions(-) -- 2.27.0