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;
From:   Steve Grubb <sgrubb@redhat.com>
To:     Phil Sutter <phil@nwl.cc>, Richard Guy Briggs <rgb@redhat.com>,
        Linux-Audit Mailing List <linux-audit@redhat.com>,
        LKML <linux-kernel@vger.kernel.org>,
        netfilter-devel@vger.kernel.org, Paul Moore <paul@paul-moore.com>,
        Ondrej Mosnacek <omosnace@redhat.com>, fw@strlen.de,
        twoerner@redhat.com, Eric Paris <eparis@parisplace.org>,
        tgraf@infradead.org, Paul Moore <paul@paul-moore.com>
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: <CAHC9VhTNQW9d=8GCW-70vAEMh8-LXviP+JHFC2-YkuitokLLMQ@mail.gmail.com>
References: <f9da8b5dbf2396b621c77c17b5b1123be5aa484e.1591275439.git.rgb@redhat.com> <20210211151606.GX3158@orbyte.nwl.cc> <CAHC9VhTNQW9d=8GCW-70vAEMh8-LXviP+JHFC2-YkuitokLLMQ@mail.gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
Precedence: bulk

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?
 
  <snip> 

> 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