Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp2465215pxb; Thu, 11 Feb 2021 13:06:37 -0800 (PST) X-Google-Smtp-Source: ABdhPJwgTw6U83TyRW8kqtRos3Tfe4OWyb9CNj2D83PnUj0BjZXrbD8HHDfxn2CjljLOssf2RmaZ X-Received: by 2002:a05:6402:1cc1:: with SMTP id ds1mr60669edb.10.1613077596978; Thu, 11 Feb 2021 13:06:36 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1613077596; cv=none; d=google.com; s=arc-20160816; b=gHv4JVs6dTN0IlVCl6W6ZbuHP467y983rBG0WzGk6hVJFhDrLLWWwkgB1F/kCmfWHQ AVG5r5J2PJJwnO3TwzDa7T5roqMQY1+E2lqGg72GU5mMHQFfalx2XU8W6cAOCVy6FWRH MhIH8LSVfjHlRNSwJlwsOclCJw/u1CjuDEocI58gEPI3cEkkdpp2fw5QDKMXNzjDSQUX LQUwynhsGfSP+OYAlAy6f+rGQBUkYGLKFP8LlGgpYvL2EzTJjEjQ+DHWlYtCr1LrEOff vsw1lVpDeVx8aXmmJhTV0xA5WoF+odC6zZ9WPtxsngEBIYChdkxfNmzG3zakbZv1YVOP kADQ== 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 :references:in-reply-to:organization:message-id:date:subject:to:from :dkim-signature; bh=jaBoUEFNY4Hfsu8q49h7KfWFimnqp7p8cmVy/yVWHcQ=; b=Us+KMLrLn1TjlrcqUh3BB+Nyc35LI9MmdWOXVvXjlb2nTnRRQErYlyFbx0vIR3Yr25 gi67ybRwlcgOia3xwsMH2vCEZ77DxHokSMKUwOXHBlK+gxY3icF1C97Kk6rAS1VbvDVK 2Wlp1jJoY4lZ92pBGkUvhipby8xtkwR+kD8j8aYvdzb9qKbqZvEHqEzl185RoAF7JXqA ieTUltiFv2s4oJ7UPGY4wngLBz2gLVUjNydRY1wAv63lfD88z2APV6C9OnJkEuHEofcZ ikMfSaB8uGpyavVqUZfKyI/hJxnA0jUK9BgvjDkFx1XDQumk2fzjjUulD4COsJK1F1FP 3DHA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=JOO7Dw5e; 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 jg13si5381551ejc.126.2021.02.11.13.06.12; Thu, 11 Feb 2021 13:06:36 -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=JOO7Dw5e; 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 S230013AbhBKVEi (ORCPT + 99 others); Thu, 11 Feb 2021 16:04:38 -0500 Received: from us-smtp-delivery-124.mimecast.com ([63.128.21.124]:59334 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229517AbhBKVEh (ORCPT ); Thu, 11 Feb 2021 16:04:37 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1613077391; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=jaBoUEFNY4Hfsu8q49h7KfWFimnqp7p8cmVy/yVWHcQ=; b=JOO7Dw5eooJTAPyRp0UnoBx6zOxcGxgUT35O+tcUwrooHMmabLNEGUrgDhhP32QgjEzq0K c9FJ4x3S36Daq40GpOTevSdNHdzirCVTuU8LOUI/c/xf1s07PTXQwuoKN4X7z5cyNHQtjv TpWARsJ08yO/dsj/SvGvOv2u/RglAiw= 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-166-2_TTrdD2OY25agubiKVEow-1; Thu, 11 Feb 2021 16:03:10 -0500 X-MC-Unique: 2_TTrdD2OY25agubiKVEow-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 C716E80403B; Thu, 11 Feb 2021 21:03:08 +0000 (UTC) Received: from x2.localnet (ovpn-118-15.rdu2.redhat.com [10.10.118.15]) by smtp.corp.redhat.com (Postfix) with ESMTP id 3B31E60636; Thu, 11 Feb 2021 21:02:57 +0000 (UTC) From: Steve Grubb To: Phil Sutter , Richard Guy Briggs , Linux-Audit Mailing List , LKML , netfilter-devel@vger.kernel.org, Paul Moore , Ondrej Mosnacek , fw@strlen.de, twoerner@redhat.com, Eric Paris , tgraf@infradead.org, Paul Moore Subject: Re: [PATCH ghak124 v3] audit: log nftables configuration change events Date: Thu, 11 Feb 2021 16:02:55 -0500 Message-ID: <4087569.ejJDZkT8p0@x2> Organization: Red Hat In-Reply-To: References: <20210211151606.GX3158@orbyte.nwl.cc> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thursday, February 11, 2021 11:29:34 AM EST Paul Moore wrote: > > 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? > 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. There are certifications which levy requirements on information flow control. The firewall can decide if information should flow or be blocked. Information flow decisions need to be auditable - which we have with the audit target. That then swings in requirements on the configuration of the information flow policy. The requirements state a need to audit any management activity - meaning the creation, modification, and/or deletion of a "firewall ruleset". Because it talks constantly about a ruleset and then individual rules, I suspect only 1 summary event is needed to say something happened, who did it, and the outcome. This would be in line with how selinux is treated: we have 1 summary event for loading/modifying/unloading selinux policy. Hope this helps... -Steve