From patchwork Wed Sep 30 16:12:24 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Steve Grubb X-Patchwork-Id: 11809849 Return-Path: Received: from mail.kernel.org (pdx-korg-mail-1.web.codeaurora.org [172.30.200.123]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 900E9618 for ; Wed, 30 Sep 2020 16:12:38 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 66F9A207FB for ; Wed, 30 Sep 2020 16:12:38 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="MlmmKMr8" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727438AbgI3QMh (ORCPT ); Wed, 30 Sep 2020 12:12:37 -0400 Received: from us-smtp-delivery-124.mimecast.com ([216.205.24.124]:23777 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725800AbgI3QMh (ORCPT ); Wed, 30 Sep 2020 12:12:37 -0400 Dkim-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1601482356; 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=7KkJqRrSkB1gl6+3x2IwQEGRxET0aPXXUe4LBKhzI2k=; b=MlmmKMr8EXls74PkuFlsfc81LHSmbXzBCqVn/mML/XvG9scsYnc0k7pLWj6jhLeP5AiSv1 wElTQWYt9txl9AYVwto628ja5us+YHoa0Swc6EuVS6s8eua8JASnDKDmWb8JmHke06b1vr Bq1d4qpSELBfnd4roGhZNApHXX535mc= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-427-YwcWIiCMP7KcDBBy25Lvgg-1; Wed, 30 Sep 2020 12:12:34 -0400 X-MC-Unique: YwcWIiCMP7KcDBBy25Lvgg-1 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 181301891E84; Wed, 30 Sep 2020 16:12:33 +0000 (UTC) Received: from x2.localnet (ovpn-117-41.rdu2.redhat.com [10.10.117.41]) by smtp.corp.redhat.com (Postfix) with ESMTP id 6E2DF1C4; Wed, 30 Sep 2020 16:12:27 +0000 (UTC) From: Steve Grubb To: linux-fsdevel@vger.kernel.org, Jan Kara , linux-audit@redhat.com, Paul Moore Cc: Amir Goldstein , Eric Paris Subject: [PATCH 1/3] fanotify: Ensure consistent variable type for response Date: Wed, 30 Sep 2020 12:12:24 -0400 Message-ID: <12617626.uLZWGnKmhe@x2> Organization: Red Hat MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org The user space API for the response variable is __u32. This patch makes sure that the whole path through the kernel uses __u32 so that there is no sign extension or truncation of the user space response. Signed-off-by: Steve Grubb --- fs/notify/fanotify/fanotify.h | 2 +- fs/notify/fanotify/fanotify_user.c | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/fs/notify/fanotify/fanotify.h b/fs/notify/fanotify/fanotify.h index 8ce7ccfc4b0d..c397993830ac 100644 --- a/fs/notify/fanotify/fanotify.h +++ b/fs/notify/fanotify/fanotify.h @@ -165,7 +165,7 @@ FANOTIFY_PE(struct fanotify_event *event) struct fanotify_perm_event { struct fanotify_event fae; struct path path; - unsigned short response; /* userspace answer to the event */ + __u32 response; /* userspace answer to the event */ unsigned short state; /* state of the event */ int fd; /* fd we passed to userspace for this event */ }; diff --git a/fs/notify/fanotify/fanotify_user.c b/fs/notify/fanotify/fanotify_user.c index 63b5dffdca9e..c8da9ea1e76e 100644 --- a/fs/notify/fanotify/fanotify_user.c +++ b/fs/notify/fanotify/fanotify_user.c @@ -157,7 +157,7 @@ static int create_fd(struct fsnotify_group *group, struct path *path, */ static void finish_permission_event(struct fsnotify_group *group, struct fanotify_perm_event *event, - unsigned int response) + __u32 response) __releases(&group->notification_lock) { bool destroy = false; @@ -178,7 +178,7 @@ static int process_access_response(struct fsnotify_group *group, { struct fanotify_perm_event *event; int fd = response_struct->fd; - int response = response_struct->response; + __u32 response = response_struct->response; pr_debug("%s: group=%p fd=%d response=%d\n", __func__, group, fd, response); From patchwork Wed Sep 30 16:12:28 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Steve Grubb X-Patchwork-Id: 11809851 Return-Path: Received: from mail.kernel.org (pdx-korg-mail-1.web.codeaurora.org [172.30.200.123]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id B9F0B112E for ; Wed, 30 Sep 2020 16:12:42 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 9111A207FB for ; Wed, 30 Sep 2020 16:12:42 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="fQBrIQ4M" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728006AbgI3QMm (ORCPT ); Wed, 30 Sep 2020 12:12:42 -0400 Received: from us-smtp-delivery-124.mimecast.com ([63.128.21.124]:36995 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725800AbgI3QMl (ORCPT ); Wed, 30 Sep 2020 12:12:41 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1601482360; 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=4pWeov0RSK9+TLECM/VJlgZplP+7FIFKwBZxev0gn2w=; b=fQBrIQ4Mh5Z2ylaiCbypP1NG9G6YTFI2nOL8CKzlCb0Eai7UJHu9t0c4wzlBbCJTnD1LRT 8jpKLvsOelGT0gaF56913+0XYVBTeZSJ7VcFWByGkLHk0g6h7eNTsWh7F2h3k5KsJ0zv6l pN00+gtvfk3UqaZ3BmNMYXIY5RrfJVQ= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-148-hynrN2KKOsq47REOTrAs7A-1; Wed, 30 Sep 2020 12:12:38 -0400 X-MC-Unique: hynrN2KKOsq47REOTrAs7A-1 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id E1BF5800475; Wed, 30 Sep 2020 16:12:36 +0000 (UTC) Received: from x2.localnet (ovpn-117-41.rdu2.redhat.com [10.10.117.41]) by smtp.corp.redhat.com (Postfix) with ESMTP id 8D92F60C07; Wed, 30 Sep 2020 16:12:33 +0000 (UTC) From: Steve Grubb To: linux-fsdevel@vger.kernel.org, Jan Kara , linux-audit@redhat.com, Paul Moore Cc: Amir Goldstein , Eric Paris Subject: [PATCH 2/3] fanotify: define bit map fields to hold response decision context Date: Wed, 30 Sep 2020 12:12:28 -0400 Message-ID: <2745105.e9J7NaK4W3@x2> Organization: Red Hat MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org This patch defines 2 bit maps within the response variable returned from user space on a permission event. The first field is 3 bits for the context type. The context type will describe what the meaning is of the second bit field. The default is none. The patch defines one additional context type which means that the second field is a rule number. This will allow for the creation of 6 other context types in the future if other users of the API identify different needs. The second field is 10 bits wide and can be used to pass along the data described by the context. Neither of these bit maps are directly adjacent and could be expanded if the need arises. To support this, several macros were created to facilitate storing and retrieving the values. There is also a macro for user space to check that the data being sent is valid. Of course, without this check, anything that overflows the bit field will trigger an EINVAL based on the use of of INVALID_RESPONSE_MASK in process_access_response(). Signed-off-by: Steve Grubb --- fs/notify/fanotify/fanotify.c | 3 +-- fs/notify/fanotify/fanotify_user.c | 7 +------ include/linux/fanotify.h | 5 +++++ include/uapi/linux/fanotify.h | 31 ++++++++++++++++++++++++++++++ 4 files changed, 38 insertions(+), 8 deletions(-) diff --git a/fs/notify/fanotify/fanotify.c b/fs/notify/fanotify/fanotify.c index 85eda539b35f..e72b7e59aa24 100644 --- a/fs/notify/fanotify/fanotify.c +++ b/fs/notify/fanotify/fanotify.c @@ -178,11 +178,10 @@ static int fanotify_get_response(struct fsnotify_group *group, } /* userspace responded, convert to something usable */ - switch (event->response & ~FAN_AUDIT) { + switch (FAN_DEC_MASK(event->response)) { case FAN_ALLOW: ret = 0; break; - case FAN_DENY: default: ret = -EPERM; } diff --git a/fs/notify/fanotify/fanotify_user.c b/fs/notify/fanotify/fanotify_user.c index c8da9ea1e76e..3b8e515904fc 100644 --- a/fs/notify/fanotify/fanotify_user.c +++ b/fs/notify/fanotify/fanotify_user.c @@ -187,13 +187,8 @@ static int process_access_response(struct fsnotify_group *group, * userspace can send a valid response or we will clean it up after the * timeout */ - switch (response & ~FAN_AUDIT) { - case FAN_ALLOW: - case FAN_DENY: - break; - default: + if (FAN_INVALID_RESPONSE_MASK(response)) return -EINVAL; - } if (fd < 0) return -EINVAL; diff --git a/include/linux/fanotify.h b/include/linux/fanotify.h index b79fa9bb7359..b3281d0e1b55 100644 --- a/include/linux/fanotify.h +++ b/include/linux/fanotify.h @@ -72,6 +72,11 @@ #define ALL_FANOTIFY_EVENT_BITS (FANOTIFY_OUTGOING_EVENTS | \ FANOTIFY_EVENT_FLAGS) +/* This mask is to check for invalid bits of a user space permission response */ +#define FAN_INVALID_RESPONSE_MASK(x) ((x) & ~(FAN_ALLOW | FAN_DENY | \ + FAN_AUDIT | FAN_DEC_CONTEXT_TYPE | \ + FAN_DEC_CONTEXT)) + /* Do not use these old uapi constants internally */ #undef FAN_ALL_CLASS_BITS #undef FAN_ALL_INIT_FLAGS diff --git a/include/uapi/linux/fanotify.h b/include/uapi/linux/fanotify.h index a88c7c6d0692..785d68ebcb58 100644 --- a/include/uapi/linux/fanotify.h +++ b/include/uapi/linux/fanotify.h @@ -152,6 +152,37 @@ struct fanotify_response { #define FAN_DENY 0x02 #define FAN_AUDIT 0x10 /* Bit mask to create audit record for result */ +/* + * User space may need to record additional information about its decision. + * The context type records what kind of information is included. A bit mask + * defines the type of information included and then the context of the + * decision. The context type is 3 bits allowing for 8 kinds of context. + * The default is none. We also define 10 bits to allow up to 1024 kinds of + * context to be returned. + * + * If the context type is Rule, then the context following is the rule number + * that triggered the user space decision. + * + * There are helper macros defined so that it can be standardized across tools. + * A full example of how user space can use this looks like this: + * + * if (FAN_DEC_CONTEXT_VALUE_VALID(rule_number)) + * response.response = FAN_DENY | FAN_AUDIT | FAN_DEC_CONTEXT_TYPE_RULE | + * FAN_DEC_CONTEXT_VALUE(rule_number); + */ +#define FAN_DEC_MASK(x) ((x) & (FAN_ALLOW|FAN_DENY)) +#define FAN_DEC_CONTEXT_TYPE 0x70000000 +#define FAN_DEC_CONTEXT 0x00FFC000 + +#define FAN_DEC_CONTEXT_TYPE_VALUE(x) (((x) & 0x07) << 28) +#define FAN_DEC_CONTEXT_TYPE_TO_VALUE(x) (((x) & FAN_DEC_CONTEXT_TYPE) >> 28) +#define FAN_DEC_CONTEXT_VALUE(x) (((x) & 0x3FF) << 14) +#define FAN_DEC_CONTEXT_TO_VALUE(x) (((x) & FAN_DEC_CONTEXT) >> 14) +#define FAN_DEC_CONTEXT_VALUE_VALID(x) ((x) >= 0 && (x) < 1024) + +#define FAN_DEC_CONTEXT_TYPE_NONE FAN_DEC_CONTEXT_TYPE_VALUE(0) +#define FAN_DEC_CONTEXT_TYPE_RULE FAN_DEC_CONTEXT_TYPE_VALUE(1) + /* No fd set in event */ #define FAN_NOFD -1 From patchwork Wed Sep 30 16:12:33 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Steve Grubb X-Patchwork-Id: 11809853 Return-Path: Received: from mail.kernel.org (pdx-korg-mail-1.web.codeaurora.org [172.30.200.123]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 77EAC618 for ; Wed, 30 Sep 2020 16:12:46 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 55AC0207FB for ; Wed, 30 Sep 2020 16:12:46 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="d2p9z/F5" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728292AbgI3QMp (ORCPT ); Wed, 30 Sep 2020 12:12:45 -0400 Received: from us-smtp-delivery-124.mimecast.com ([216.205.24.124]:42831 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725800AbgI3QMp (ORCPT ); Wed, 30 Sep 2020 12:12:45 -0400 Dkim-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1601482364; 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=wZ7hKbJIHYqalK4WOUAGK/bFKZtga8tBuJ3icBPBGgc=; b=d2p9z/F5ZdYPI9iMabDkle2qsUK7ggehXUn3h6Ijp02AcVDnMfXNPuQBBp6foCUeZJgXi2 zyW7EICyJrem7z0GqSQ2Icv2BQkMsz0PADV1M1VS8vUXd1lWkpi69cxVo9AcJDAoeNZpUP M/ETT3E4I55GbEhnKYEAdrWIQKDk7sw= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-595-SJaR17A5PUeqQT0hzkX90A-1; Wed, 30 Sep 2020 12:12:42 -0400 X-MC-Unique: SJaR17A5PUeqQT0hzkX90A-1 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 0671364080; Wed, 30 Sep 2020 16:12:41 +0000 (UTC) Received: from x2.localnet (ovpn-117-41.rdu2.redhat.com [10.10.117.41]) by smtp.corp.redhat.com (Postfix) with ESMTP id 5F33D5C1CF; Wed, 30 Sep 2020 16:12:37 +0000 (UTC) From: Steve Grubb To: linux-fsdevel@vger.kernel.org, Jan Kara , linux-audit@redhat.com, Paul Moore Cc: Amir Goldstein , Eric Paris Subject: [PATCH 3/3] fanotify: Allow audit to use the full permission event response Date: Wed, 30 Sep 2020 12:12:33 -0400 Message-ID: <3075502.aeNJFYEL58@x2> Organization: Red Hat MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org This patch unmasks the full value so that the audit function can use all of it. 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 ctx_type=1 fan_ctx=17 Signed-off-by: Steve Grubb --- fs/notify/fanotify/fanotify.c | 2 +- kernel/auditsc.c | 7 +++++-- 2 files changed, 6 insertions(+), 3 deletions(-) diff --git a/fs/notify/fanotify/fanotify.c b/fs/notify/fanotify/fanotify.c index e72b7e59aa24..a9278e983e30 100644 --- a/fs/notify/fanotify/fanotify.c +++ b/fs/notify/fanotify/fanotify.c @@ -188,7 +188,7 @@ static int fanotify_get_response(struct fsnotify_group *group, /* Check if the response should be audited */ if (event->response & FAN_AUDIT) - audit_fanotify(event->response & ~FAN_AUDIT); + audit_fanotify(event->response); pr_debug("%s: group=%p event=%p about to return ret=%d\n", __func__, group, event, ret); diff --git a/kernel/auditsc.c b/kernel/auditsc.c index fd840c40abf7..9d6a3ad2037d 100644 --- a/kernel/auditsc.c +++ b/kernel/auditsc.c @@ -75,6 +75,7 @@ #include #include #include +#include #include "audit.h" @@ -2523,8 +2524,10 @@ void __audit_log_kern_module(char *name) void __audit_fanotify(unsigned int response) { - audit_log(audit_context(), GFP_KERNEL, - AUDIT_FANOTIFY, "resp=%u", response); + audit_log(audit_context(), GFP_KERNEL, AUDIT_FANOTIFY, + "resp=%u ctx_type=%u fan_ctx=%u", FAN_DEC_MASK(response), + FAN_DEC_CONTEXT_TYPE_TO_VALUE(response), + FAN_DEC_CONTEXT_TO_VALUE(response)); } void __audit_tk_injoffset(struct timespec64 offset)