Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp2443531pxb; Thu, 11 Feb 2021 12:29:13 -0800 (PST) X-Google-Smtp-Source: ABdhPJxsKvIjrJbtbT8Njrc8RQyRSMRgLwBtveFNsYlMrw64SKR92hsO4mgUpIhWkJfbUSxewWS4 X-Received: by 2002:a17:906:d8b5:: with SMTP id qc21mr9736700ejb.62.1613075353253; Thu, 11 Feb 2021 12:29:13 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1613075353; cv=none; d=google.com; s=arc-20160816; b=v8z7VILLRLuSlnn4JfO+JL/h4aMjiQRahNJ1Qs6qoyK5xtCehN6pp1VVUZ2yCrhoGW Yxn9IaHF9R0okVadqGp0mH7h7RebSXGyvNGwLJLyfrpRIcLSUrwHSbN8MGb0SmHclrdZ ZWoOblyTSmC0iaG0igVK8WD8YFFumhrUYEyQoQtTb40YfLscCoDyyJDvBmOSx+edLYeG 0tgWDsi4z59XrVFyvTsSMBSQyP1B1eNjg9rSMCcctRO9IZqwmRAp/GixI59RfP2tAuif gpuxCBzGR/GAVKjjMIbU+TIGyW1naRJTN8fnhgys0VDsO9KExwVmJJ12m03FMEOkiHKR HkTg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature; bh=kedDsP6t4VP3mQxBac2ERpSJUqeZHmbTEmxpDibNovU=; b=diirLA9FFb2iwyfpb3xYdIGa34XffUYPKRIGXc79vS3gdpb1ubGUeO5GQRDrT1gMMj 51BvlJZJlwiU3hYn15CDmA8UlmQPAQHhYHy11lPp0c+Tc4ItmI6yAONj0mqA73CzEbAs dlo4myG2wSmTMb0LKgk7LgTKPio715wYPpQKj+4Iz1unTQi6FT/7+AKVBRxAa+g+xfap yWc9as8Dtx99QWi+tsnBjFrXSAFm0pbwvyyChS+D0jG5RfiSFekHztvjRarpm5rDDSfh l76bl/nk2sd6+0UY1oZyCI3EccbSFjWn2JUdJ6YKZEL0MM1in+zXGqDJruLuKxZRM/6f EWzw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=LWf3uN0v; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 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 vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id bx22si4362899edb.142.2021.02.11.12.28.50; Thu, 11 Feb 2021 12:29:13 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=LWf3uN0v; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 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 S230005AbhBKU2O (ORCPT + 99 others); Thu, 11 Feb 2021 15:28:14 -0500 Received: from us-smtp-delivery-124.mimecast.com ([63.128.21.124]:46564 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230412AbhBKU2M (ORCPT ); Thu, 11 Feb 2021 15:28:12 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1613075205; 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: in-reply-to:in-reply-to:references:references; bh=kedDsP6t4VP3mQxBac2ERpSJUqeZHmbTEmxpDibNovU=; b=LWf3uN0v3CbAbIhB0ZoJlRLMwBYT1YKR7r+bqjBP7i047Enmgom3BZkXWUXptkwJyDwjdS ooK+195f1lVqxX2idxA07OyCCXh4u27HFlTWsyNQCVy+u1j94GcbB0Ybq1l5R9qtdkBfUJ pqgK58ay70u60bziZIZ4quJsY0vvWcU= 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-572--4GrNyaBNIuCrTTI0FGh6g-1; Thu, 11 Feb 2021 15:26:41 -0500 X-MC-Unique: -4GrNyaBNIuCrTTI0FGh6g-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 E5EEB80196E; Thu, 11 Feb 2021 20:26:39 +0000 (UTC) Received: from madcap2.tricolour.ca (unknown [10.10.110.8]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 595AC6F998; Thu, 11 Feb 2021 20:26:31 +0000 (UTC) Date: Thu, 11 Feb 2021 15:26:28 -0500 From: Richard Guy Briggs To: Paul Moore Cc: Phil Sutter , Linux-Audit Mailing List , LKML , netfilter-devel@vger.kernel.org, sgrubb@redhat.com, Ondrej Mosnacek , fw@strlen.de, twoerner@redhat.com, Eric Paris , tgraf@infradead.org Subject: Re: [PATCH ghak124 v3] audit: log nftables configuration change events Message-ID: <20210211202628.GP2015948@madcap2.tricolour.ca> References: <20210211151606.GX3158@orbyte.nwl.cc> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2021-02-11 11:29, Paul Moore wrote: > On Thu, Feb 11, 2021 at 10:16 AM Phil Sutter wrote: > > Hi, > > > > On Thu, Jun 04, 2020 at 09:20:49AM -0400, Richard Guy Briggs wrote: > > > iptables, ip6tables, arptables and ebtables table registration, > > > replacement and unregistration configuration events are logged for the > > > native (legacy) iptables setsockopt api, but not for the > > > nftables netlink api which is used by the nft-variant of iptables in > > > addition to nftables itself. > > > > > > Add calls to log the configuration actions in the nftables netlink api. > > > > As discussed offline already, these audit notifications are pretty hefty > > performance-wise. In an internal report, 300% restore time of a ruleset > > containing 70k set elements is measured. > > If you're going to reference offline/off-list discussions in a post to > a public list, perhaps the original discussion shouldn't have been > off-list ;) If you don't involve us in the discussion, we have to > waste a lot of time getting caught up. Here's part of that discussion: https://bugzilla.redhat.com/show_bug.cgi?id=1918013 > > If I'm not mistaken, iptables emits a single audit log per table, ipset > > doesn't support audit at all. So I wonder how much audit logging is > > required at all (for certification or whatever reason). How much > > granularity is desired? > > That's a question for the people who track these certification > requirements, which is thankfully not me at the moment. Unless > somebody else wants to speak up, Steve Grubb is probably the only > person who tracks that sort of stuff and comments here. > > I believe the netfilter auditing was mostly a nice-to-have bit of > functionality to help add to the completeness of the audit logs, but I > could very easily be mistaken. Richard put together those patches, he > can probably provide the background/motivation for the effort. It was added because an audit test that normally produced records from iptables on one distro stopped producing any records on another. Investigation led to the fact that on the first it was using iptables-legacy API and on the other it was using iptables-nft API. > > I personally would notify once per transaction. This is easy and quick. This was the goal. iptables was atomic. nftables appears to no longer be so. If I have this wrong, please show how that works. > > Once per table or chain should be acceptable, as well. At the very > > least, we should not have to notify once per each element. This is the > > last resort of fast ruleset adjustments. If we lose it, people are > > better off with ipset IMHO. > > > > Unlike nft monitor, auditd is not designed to be disabled "at will". So > > turning it off for performance-critical workloads is no option. If it were to be disabled "at will" it would defeat the purpose of audit. Those records can already be filtered, or audit can be disabled, but let us look at rationalizing the current nftables records first. > Patches are always welcome, but it might be wise to get to the bottom > of the certification requirements first. > > -- > paul moore > www.paul-moore.com > > -- > Linux-audit mailing list > Linux-audit@redhat.com > https://www.redhat.com/mailman/listinfo/linux-audit - RGB -- Richard Guy Briggs Sr. S/W Engineer, Kernel Security, Base Operating Systems Remote, Ottawa, Red Hat Canada IRC: rgb, SunRaycer Voice: +1.647.777.2635, Internal: (81) 32635