Received: by 2002:a05:6358:a55:b0:ec:fcf4:3ecf with SMTP id 21csp5562200rwb; Tue, 17 Jan 2023 15:47:13 -0800 (PST) X-Google-Smtp-Source: AMrXdXvDf8uOAHPyJrxm4ImVtiPCCRh+ZBx90klmHHBvcmXrJ/Lo7XHwXomfkbEsGMLE/s7OHT8A X-Received: by 2002:a17:902:c948:b0:194:6414:12e1 with SMTP id i8-20020a170902c94800b00194641412e1mr7299635pla.25.1673999233531; Tue, 17 Jan 2023 15:47:13 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1673999233; cv=none; d=google.com; s=arc-20160816; b=GDNwfbjz8jm7kGScRHZPmA1SCht7edlt+hrE3KSFoCk7NYwczs2+EjPRHTx5gXbqSD ZzvTg0/1q0TMSDrIMzyavVS9kxK1xwpihhHYyBPXpBPJBzRkDEi1uwwkpIpURhwnefCy 1s2y38Y48JyffHuD+1tBNhfVdxjws6aT71PT3Klh4LNDEMpCeMQDhknNgBRhSLZx0HGw LmHYFzyM54nfg8u3MV11bD7e7zynby6A3fBxEaA6KgFbfbf01kCXNagbdpDM4HSDhxf3 FBoJJVK1jOBn8nc1uOzjKv52LGTBYfZQabKKry/j+D7dCAybQh/e5Z/gQywPQAJmnQPn E6sg== 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=BLiSOjNb0xDOzALeAyTD+mR9sLdYm4aLnwXALKfDdxk=; b=V5mWt35ZylRBpBoV4C/xFFDKpQj/HCPnSn1uvsfSg5yaSrqN5Vf3A/BkcPgJnvRuDk UdczQRziMkyeiziHP5J4npsStC3oLMjsf9Ba/so5n7x5efhSsis4Q9ywh1tr3ogPksen 7HHYqexVzAOaQEk5qy7WC2+pYwgxG2AMydHDgmBT39srG++5fjMBYcqfucrEk/vnCzkM YQVkrd4BLEvRA1uZC4ttVDrHGSJ30dym5Ygz3zy+Q467icwj39l8WCNdbKEL7yDu2L84 8Tj8h171ukHSG3m0jEKyrqRI4JX39OPO5Dwz70jjNavWZbf1/bFKcCTNKXV0w6xeX7Ml b9iQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=N+kwymQd; 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 d8-20020a170903230800b00174c5fdc8d2si12436728plh.307.2023.01.17.15.47.07; Tue, 17 Jan 2023 15:47:13 -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=@redhat.com header.s=mimecast20190719 header.b=N+kwymQd; 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 S229909AbjAQXYh (ORCPT + 46 others); Tue, 17 Jan 2023 18:24:37 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45324 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229845AbjAQXXw (ORCPT ); Tue, 17 Jan 2023 18:23:52 -0500 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8DCE46D36B for ; Tue, 17 Jan 2023 13:14:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1673990062; 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=BLiSOjNb0xDOzALeAyTD+mR9sLdYm4aLnwXALKfDdxk=; b=N+kwymQd5LkoAZX8fi7tFQx4+/5Q4KGh9lJvuiVQI7zD6C8Z+yIkHr8T7cqBzwyJ4QvdCH ABp/zKFozLX8J9YRV6eSFlE41VgTXJAwNiiU94TApZYBToMzMGw+JI8BEgR5bbXMy6Lb0W GXTOtTZ2fMw+Yr89wOlw0EjJwp1y5go= 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-118-j3vvkZ7oNiyvg7oiQl3fyQ-1; Tue, 17 Jan 2023 16:14:19 -0500 X-MC-Unique: j3vvkZ7oNiyvg7oiQl3fyQ-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 0389680D180; Tue, 17 Jan 2023 21:14:19 +0000 (UTC) Received: from madcap2.tricolour.com (ovpn-0-3.rdu2.redhat.com [10.22.0.3]) by smtp.corp.redhat.com (Postfix) with ESMTP id 84C2EC15BAD; Tue, 17 Jan 2023 21:14:17 +0000 (UTC) From: Richard Guy Briggs To: Linux-Audit Mailing List , LKML , linux-fsdevel@vger.kernel.org, linux-api@vger.kernel.org Cc: Paul Moore , Eric Paris , Steve Grubb , Richard Guy Briggs , Jan Kara , Amir Goldstein Subject: [PATCH v6 0/3] fanotify: Allow user space to pass back additional audit info Date: Tue, 17 Jan 2023 16:14:04 -0500 Message-Id: MIME-Version: 1.0 Content-type: text/plain Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 3.1 on 10.11.54.8 X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE 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 patchset defines a new flag (FAN_INFO) and new extensions that define additional information which are appended after the response structure returned from user space on a permission event. The appended information is organized with headers containing a type and size that can be delegated to interested subsystems. One new information type is defined to audit the triggering rule number. A newer kernel will work with an older userspace and an older kernel will behave as expected and reject a newer userspace, leaving it up to the newer userspace to test appropriately and adapt as necessary. This is done by providing a a fully-formed FAN_INFO extension but setting the fd to FAN_NOFD. On a capable kernel, it will succeed but issue no audit record, whereas on an older kernel it will fail. The audit function was updated to log the additional information in the AUDIT_FANOTIFY record. The following are examples of the new record format: type=FANOTIFY msg=audit(1600385147.372:590): resp=2 fan_type=1 fan_info=3137 subj_trust=3 obj_trust=5 type=FANOTIFY msg=audit(1659730979.839:284): resp=1 fan_type=0 fan_info=3F subj_trust=? obj_trust=? 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/all/cover.1652730821.git.rgb@redhat.com v4: - scrap FAN_INVALID_RESPONSE_MASK in favour of original to catch invalid response == 0 - introduce FANOTIFY_RESPONSE_* macros - uapi: remove union - keep original struct fanotify_response, add fan_info infra starting with audit reason - uapi add struct fanotify_response_info_header{type/pad/len} and struct fanotify_response_info_audit_rule{hdr/rule} - rename fan_ctx= to fan_info=, FAN_EXTRA to FAN_INFO - change event struct from type/buf to len/buf - enable multiple info extensions in one message - hex encode fan_info in __audit_fanotify() - record type FANOTIFY extended to "type=FANOTIFY msg=audit(1659730979.839:284): resp=1 fan_type=0 fan_info=3F" Link: https://lore.kernel.org/all/cover.1659996830.git.rgb@redhat.com v5: - fixed warnings in p2/4 and p3/4 found by - restore original behaviour for !FAN_INFO case and fanotify_get_response() - rename member audit_rule to rule_number - eliminate memory leak of info_buf on failure (no longer dynamic) - rename buf:info, count:info_len, c:remain, ib:infop - fix pr_debug - return -ENOENT on FAN_INFO and fd==FAN_NOFD to signal new kernel - fanotify_write() remove redundant size check - add u32 subj_trust obj_trust fields with unknown value "2" - split out to helper process_access_response_info() - restore finish_permission_event() response_struct to u32 - assume and enforce one rule to audit, pass struct directly to __audit_fanotify() - change fanotify_perm_event struct to union hdr/audir_rule - add vspace to fanotify_write() and process_access_response_info() - squash 3/4 with 4/4 - fix v3 and v4 links Link: https://lore.kernel.org/all/cover.1670606054.git.rgb@redhat.com v6: - simplify __audit_fanotify() from audit_log_format/audit_log_n_hex to audit_log/%X - add comment to clarify {subj,obj}_trust values - remove fd processing from process_access_response_info() - return info_len immediately from process_access_response() on FAN_NOFD after process_access_response_info() Link: https://lore.kernel.org/all/cover.1673989212.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,audit: Allow audit to use the full permission event response fs/notify/fanotify/fanotify.c | 8 ++- fs/notify/fanotify/fanotify.h | 6 +- fs/notify/fanotify/fanotify_user.c | 88 ++++++++++++++++++++++-------- include/linux/audit.h | 9 +-- include/linux/fanotify.h | 5 ++ include/uapi/linux/fanotify.h | 30 +++++++++- kernel/auditsc.c | 16 +++++- 7 files changed, 129 insertions(+), 33 deletions(-) -- 2.27.0