Received: by 2002:a6b:500f:0:0:0:0:0 with SMTP id e15csp3324454iob; Mon, 16 May 2022 19:25:45 -0700 (PDT) X-Google-Smtp-Source: ABdhPJw6B4HqVw3vYUoNBEEA9bXDu2PTGaySyiUkqva2qqWsyQlW7LH1n+cwXKoIBcLz0++d+p+E X-Received: by 2002:a17:907:7207:b0:6f4:43df:abff with SMTP id dr7-20020a170907720700b006f443dfabffmr17604775ejc.681.1652754345188; Mon, 16 May 2022 19:25:45 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1652754345; cv=none; d=google.com; s=arc-20160816; b=TD3lP/oDBEMp7Z5OhI5qdKikhRxd1GlQ0n3GejUHbRD+I4S+ES7YRy2E5yrlfpI0+k TOfZtIb0KH2rZhDEYcrNTf6mffy0vQTDQK42KFNEUeUNVBo74GSDp+E6rsGJYWG/wxBX Q9AfTMTQyur/sRfp97eBxA+pzfjeMtcjwvOPW9IlsxYiQ3VUHmTfpgVo8kSnDrGAUqaG jfOsgaBh6NudHaDVeBa3e3TiMjy/OV4siaqxLUy/8/QVdLLqcBGpbtgTNnTasbP3u5OG Gf06uMyyoJbRgr/Ju3Mn/pLqFunQA7s3/4js80a3LFTL0FRhp5xhPragE5BBo5nVJfLJ mYkA== 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=X/hW8heDuAXy8YNMnWK8A1edgrFI+3cNEUxDQuZBP/o=; b=Cdg4XBGQu5Q2OAfJG2Tm4TQVyxyV4UXMCo/DpoNSjjI+Qut4Emt6Xaaq8aUVRLbWfR q5dTK5LoNxuBht8tgqzAchUrMvj2h3xwTGGRNURPrOsoAJUZKNDnA+L7Kh6O7Vr5lR55 5aq749bMmkoXwmQNbXianuNkFsxqOFpxKKcJ4yE3eAZzbTbPpcI809NS0hAbOfdlJ+QA LbRBsI7kXb+cwvTOzF5V3L+3XTUUzafrfOlN2Vp68e9mqCdH8HDoNqpEOKkvnClxBIXK ygeewtUtGUwEennm60JswPL5yivIWarYePLyeh4MY8om4V/VXuxrLCWP8UK8ZgsN9R1R VORg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=UQeDOVHC; 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 o14-20020a170906974e00b006df76385bbasi1197847ejy.90.2022.05.16.19.25.19; Mon, 16 May 2022 19:25:45 -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=UQeDOVHC; 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 S1348089AbiEPUsG (ORCPT + 99 others); Mon, 16 May 2022 16:48:06 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53192 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S245613AbiEPUpC (ORCPT ); Mon, 16 May 2022 16:45:02 -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 ESMTP id CF10F483A1 for ; Mon, 16 May 2022 13:22:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1652732560; 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=X/hW8heDuAXy8YNMnWK8A1edgrFI+3cNEUxDQuZBP/o=; b=UQeDOVHCYtY5VXaBS1VP0SqjLx7lfaTm2deatoxkjZQ8JECGgukXIn2Q0SgO9vEWv847AH 4WHL5Tv9uJhuSxVbCOCzuI6vR7o59GQJHcuAiVWnUwxkD/RMwWfqVKjRn4cU6ZjlGp9pSR atbe6GEIPOaC0xhZ3D25vzLrXCJcQWs= 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-595-0tAPI_2OPfONwKeE-BDOkg-1; Mon, 16 May 2022 16:22:36 -0400 X-MC-Unique: 0tAPI_2OPfONwKeE-BDOkg-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.rdu2.redhat.com [10.11.54.1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 26CC1811E75; Mon, 16 May 2022 20:22:36 +0000 (UTC) Received: from madcap2.tricolour.com (unknown [10.22.50.7]) by smtp.corp.redhat.com (Postfix) with ESMTP id A783840CF8E2; Mon, 16 May 2022 20:22:34 +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 , Amir Goldstein Subject: [PATCH v3 0/3] fanotify: Allow user space to pass back additional audit info Date: Mon, 16 May 2022 16:22:21 -0400 Message-Id: MIME-Version: 1.0 Content-type: text/plain Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.84 on 10.11.54.1 X-Spam-Status: No, score=-3.1 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,T_SCC_BODY_TEXT_LINE autolearn=unavailable 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 32 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 v3: - 1/3 switch {,__}audit_fanotify() from uint to u32 - 2/3 re-add fanotify_get_response switch case FAN_DENY: to avoid unnecessary churn - add FAN_EXTRA flag to indicate more info and break with old kernel - change response from u16 to u32 to avoid endian issues - change extra_info_buf to union - move low-cost fd check earlier - change FAN_RESPONSE_INFO_AUDIT_NONE to FAN_RESPONSE_INFO_NONE - switch to u32 for internal and __u32 for uapi Link: https://lore.kernel.org/r/cover.1652724390.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 | 6 ++- fs/notify/fanotify/fanotify.h | 4 +- fs/notify/fanotify/fanotify_user.c | 76 +++++++++++++++++++----------- include/linux/audit.h | 9 ++-- include/linux/fanotify.h | 3 ++ include/uapi/linux/fanotify.h | 22 ++++++++- kernel/auditsc.c | 18 +++++-- 7 files changed, 100 insertions(+), 38 deletions(-) -- 2.27.0