On 2021-02-11 15:26, Richard Guy Briggs wrote: > On 2021-02-11 11:29, Paul Moore wrote: > > On Thu, Feb 11, 2021 at 10:16 AM Phil Sutter <phil@xxxxxx> 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 Here's the rest: https://bugzilla.redhat.com/show_bug.cgi?id=1921624 > > > 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 > > - RGB - RGB -- Richard Guy Briggs <rgb@xxxxxxxxxx> 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
