From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.0 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE, SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 81069C2BB55 for ; Mon, 13 Apr 2020 02:52:00 +0000 (UTC) Received: from us-smtp-1.mimecast.com (us-smtp-delivery-1.mimecast.com [205.139.110.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 341DE20705 for ; Mon, 13 Apr 2020 02:51:59 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="BMPMGk6E" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 341DE20705 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=linux-audit-bounces@redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1586746319; h=from:from:sender:sender: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: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post; bh=cCaSwp3mc9LB9n/LoYz7RrVC9Ne7goPGIgTRDmT8BLw=; b=BMPMGk6EqlUv5Npc6QuK6ooafy/XPTueAN0x7a9QXvnxbDzVkLNyP5Ba+OPRr9f7qpD2F2 bZuN3ERr7LvJBUL4skkPqqNOegQ1/d2gYZ/BTGVwd1NetVWRg+e/vyHeyVfONs6XYWY4k/ uX88gVWDvUD23zn+7Jup2avDp5dMkcQ= 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-52-s_6h_5C2MSKkhyvhh_X84A-1; Sun, 12 Apr 2020 22:51:56 -0400 X-MC-Unique: s_6h_5C2MSKkhyvhh_X84A-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id EDE9F18B642C; Mon, 13 Apr 2020 02:51:52 +0000 (UTC) Received: from colo-mx.corp.redhat.com (colo-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.20]) by smtp.corp.redhat.com (Postfix) with ESMTPS id CE41650C01; Mon, 13 Apr 2020 02:51:52 +0000 (UTC) Received: from lists01.pubmisc.prod.ext.phx2.redhat.com (lists01.pubmisc.prod.ext.phx2.redhat.com [10.5.19.33]) by colo-mx.corp.redhat.com (Postfix) with ESMTP id 937E118089CD; Mon, 13 Apr 2020 02:51:52 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) by lists01.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id 03BN5Kv3002581 for ; Sat, 11 Apr 2020 19:05:20 -0400 Received: by smtp.corp.redhat.com (Postfix) id 9B08D2166B35; Sat, 11 Apr 2020 23:05:20 +0000 (UTC) Received: from mimecast-mx02.redhat.com (mimecast02.extmail.prod.ext.rdu2.redhat.com [10.11.55.18]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 96E122166B34 for ; Sat, 11 Apr 2020 23:05:18 +0000 (UTC) Received: from us-smtp-1.mimecast.com (us-smtp-delivery-1.mimecast.com [205.139.110.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 442B18007D2 for ; Sat, 11 Apr 2020 23:05:18 +0000 (UTC) Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-360-nLtuoIKzPI2fLQUOydbwxQ-1; Sat, 11 Apr 2020 19:05:15 -0400 X-MC-Unique: nLtuoIKzPI2fLQUOydbwxQ-1 Received: from sasha-vm.mshome.net (c-73-47-72-35.hsd1.nh.comcast.net [73.47.72.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 4AB7D214D8; Sat, 11 Apr 2020 23:05:13 +0000 (UTC) From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Subject: [PATCH AUTOSEL 5.6 070/149] audit: CONFIG_CHANGE don't log internal bookkeeping as an event Date: Sat, 11 Apr 2020 19:02:27 -0400 Message-Id: <20200411230347.22371-70-sashal@kernel.org> In-Reply-To: <20200411230347.22371-1-sashal@kernel.org> References: <20200411230347.22371-1-sashal@kernel.org> MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore X-Scanned-By: MIMEDefang 2.78 on 10.11.54.6 X-MIME-Autoconverted: from quoted-printable to 8bit by lists01.pubmisc.prod.ext.phx2.redhat.com id 03BN5Kv3002581 X-loop: linux-audit@redhat.com X-Mailman-Approved-At: Sun, 12 Apr 2020 22:49:46 -0400 Cc: Sasha Levin , linux-audit@redhat.com X-BeenThere: linux-audit@redhat.com X-Mailman-Version: 2.1.12 Precedence: junk List-Id: Linux Audit Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit From: Steve Grubb [ Upstream commit 70b3eeed49e8190d97139806f6fbaf8964306cdb ] Common Criteria calls out for any action that modifies the audit trail to be recorded. That usually is interpreted to mean insertion or removal of rules. It is not required to log modification of the inode information since the watch is still in effect. Additionally, if the rule is a never rule and the underlying file is one they do not want events for, they get an event for this bookkeeping update against their wishes. Since no device/inode info is logged at insertion and no device/inode information is logged on update, there is nothing meaningful being communicated to the admin by the CONFIG_CHANGE updated_rules event. One can assume that the rule was not "modified" because it is still watching the intended target. If the device or inode cannot be resolved, then audit_panic is called which is sufficient. The correct resolution is to drop logging config_update events since the watch is still in effect but just on another unknown inode. Signed-off-by: Steve Grubb Signed-off-by: Paul Moore Signed-off-by: Sasha Levin --- kernel/audit_watch.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/kernel/audit_watch.c b/kernel/audit_watch.c index 4508d5e0cf696..8a8fd732ff6d0 100644 --- a/kernel/audit_watch.c +++ b/kernel/audit_watch.c @@ -302,8 +302,6 @@ static void audit_update_watch(struct audit_parent *parent, if (oentry->rule.exe) audit_remove_mark(oentry->rule.exe); - audit_watch_log_rule_change(r, owatch, "updated_rules"); - call_rcu(&oentry->rcu, audit_free_rule_rcu); } -- 2.20.1 -- Linux-audit mailing list Linux-audit@redhat.com https://www.redhat.com/mailman/listinfo/linux-audit From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-10.1 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_GIT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2A35FC2BBC7 for ; Sat, 11 Apr 2020 23:05:19 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id EE61A20CC7 for ; Sat, 11 Apr 2020 23:05:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1586646319; bh=6ujQpcxIGithtYCTLKGJdniW/4CHxY9NdvXu1hLNzmU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=iXa0kEB4hNm15qrV9KQ6M8VQuYCfx3dte1J/yUd+DtkUCvWSmvfXQkfgwn3RAfKjH gWl8INxkYhAuhC8WVHRLEK/rhs6z3CRHyL1L6lzOPWbDEJcYJoUIEYlzSwARlffONn yIHdNIzSa7/rTZ5/9uJlX/TxR3A3NTAu4plxUApE= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727891AbgDKXFR (ORCPT ); Sat, 11 Apr 2020 19:05:17 -0400 Received: from mail.kernel.org ([198.145.29.99]:39110 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727851AbgDKXFN (ORCPT ); Sat, 11 Apr 2020 19:05:13 -0400 Received: from sasha-vm.mshome.net (c-73-47-72-35.hsd1.nh.comcast.net [73.47.72.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 4AB7D214D8; Sat, 11 Apr 2020 23:05:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1586646313; bh=6ujQpcxIGithtYCTLKGJdniW/4CHxY9NdvXu1hLNzmU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=kL81xW8Tm5coN1QxiZzoEFvudor1y/QlYPgrMSH6ZTb1F0XD6+8psJksCDwTi9a8J Xjy5iaGLyk4Q8IEchBts44xnV0C3H9P7Ll3cWE7lN6y5ZzPkY7ZPPK1Ox436Dpe82o 5BYKUZIK98JOjgCqjRhyeNFaNa4Ncgo+FABK5oEU= From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Steve Grubb , Paul Moore , Sasha Levin , linux-audit@redhat.com Subject: [PATCH AUTOSEL 5.6 070/149] audit: CONFIG_CHANGE don't log internal bookkeeping as an event Date: Sat, 11 Apr 2020 19:02:27 -0400 Message-Id: <20200411230347.22371-70-sashal@kernel.org> X-Mailer: git-send-email 2.20.1 In-Reply-To: <20200411230347.22371-1-sashal@kernel.org> References: <20200411230347.22371-1-sashal@kernel.org> MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Steve Grubb [ Upstream commit 70b3eeed49e8190d97139806f6fbaf8964306cdb ] Common Criteria calls out for any action that modifies the audit trail to be recorded. That usually is interpreted to mean insertion or removal of rules. It is not required to log modification of the inode information since the watch is still in effect. Additionally, if the rule is a never rule and the underlying file is one they do not want events for, they get an event for this bookkeeping update against their wishes. Since no device/inode info is logged at insertion and no device/inode information is logged on update, there is nothing meaningful being communicated to the admin by the CONFIG_CHANGE updated_rules event. One can assume that the rule was not "modified" because it is still watching the intended target. If the device or inode cannot be resolved, then audit_panic is called which is sufficient. The correct resolution is to drop logging config_update events since the watch is still in effect but just on another unknown inode. Signed-off-by: Steve Grubb Signed-off-by: Paul Moore Signed-off-by: Sasha Levin --- kernel/audit_watch.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/kernel/audit_watch.c b/kernel/audit_watch.c index 4508d5e0cf696..8a8fd732ff6d0 100644 --- a/kernel/audit_watch.c +++ b/kernel/audit_watch.c @@ -302,8 +302,6 @@ static void audit_update_watch(struct audit_parent *parent, if (oentry->rule.exe) audit_remove_mark(oentry->rule.exe); - audit_watch_log_rule_change(r, owatch, "updated_rules"); - call_rcu(&oentry->rcu, audit_free_rule_rcu); } -- 2.20.1