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;
MIME-Version: 1.0
References: <f9da8b5dbf2396b621c77c17b5b1123be5aa484e.1591275439.git.rgb@redhat.com>
 <20210211151606.GX3158@orbyte.nwl.cc>
In-Reply-To: <20210211151606.GX3158@orbyte.nwl.cc>
From:   Paul Moore <paul@paul-moore.com>
Date:   Thu, 11 Feb 2021 11:29:34 -0500
Message-ID: <CAHC9VhTNQW9d=8GCW-70vAEMh8-LXviP+JHFC2-YkuitokLLMQ@mail.gmail.com>
Subject: Re: [PATCH ghak124 v3] audit: log nftables configuration change events
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>,
        sgrubb@redhat.com, Ondrej Mosnacek <omosnace@redhat.com>,
        fw@strlen.de, twoerner@redhat.com,
        Eric Paris <eparis@parisplace.org>, tgraf@infradead.org
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Thu, Feb 11, 2021 at 10:16 AM Phil Sutter <phil@nwl.cc> 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.

> 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.

> I personally would notify once per transaction. This is easy and quick.
> 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.

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