I really don't know what the component is.

It might be even the kernel itself.

Please change if necessary.

As far as I understand no such messages were logged with kernels < 5.10

Let's blame the kernel actually.

The kernel is the source of this. But systemd enables the audit system unless it's booted with audit=0. If you wanted to suppress this one type of event, you can load the following audit rule:

-a always,exclude -F msgtype=NETFILTER_CFG

and that should make it go away.

What Steve said.

These are intentional, logging all changes to the configuration of the audit system which are required for security certifications.  Unfortunately, there are more with nftables compared with iptables due to their calling method.

Upstream: https://github.com/linux-audit/audit-kernel/issues/124

(In reply to Steve Grubb from comment #3)

Again, these messages seem not to have any meaning or importance and I'd love them to be disabled by default without (re)configuring anything. Again, they were not present in earlier kernel versions.

(In reply to Richard Guy Briggs from comment #4)

I haven't changed anything in regard to my firewall rules since forever. I'm not against auditing, I'm against meaningless auditing.

(In reply to Artem S. Tashkinov from comment #5)
> (In reply to Steve Grubb from comment #3)
> Again, these messages seem not to have any meaning or importance and I'd love them to be disabled by default without (re)configuring anything. Again, they were not present in earlier kernel versions.

They were already present for iptables, just not as numerous [2011-01-16 fbabf31e4d48 ("netfilter: create audit records for x_tables replaces")].  Part of the reason they seem repetetive is because there is missing network namespace identification (which is planned) which was already an issue for iptables.

> (In reply to Richard Guy Briggs from comment #4)
> I haven't changed anything in regard to my firewall rules since forever. I'm not against auditing, I'm against meaningless auditing.

There was consultation with the netfilter-devs to be sure to catch all changes with a consistent format that accommodates all varieties of possible information while minimizing the number of messages to do so.  There is willingness to revisit it without breaking backward compatibility.

If you don't want any messages, set the kernel command line to audit=0.

(In reply to Richard Guy Briggs from comment #6)

> If you don't want any messages, set the kernel command line to audit=0.

I'm OK with security audit messages.

What I'm seeing is plain SPAM, e.g.:

NETFILTER_CFG table=filter family=7 entries=0 op=xt_unregister pid=325361 subj=system_u:system_r:kernel_t:s0 comm="kworker/u8:5"
NETFILTER_CFG table=filter family=7 entries=0 op=xt_unregister pid=325361 subj=system_u:system_r:kernel_t:s0 comm="kworker/u8:5"
NETFILTER_CFG table=filter family=7 entries=0 op=xt_unregister pid=325361 subj=system_u:system_r:kernel_t:s0 comm="kworker/u8:5"

Three identical messages being logged.

(In reply to Artem S. Tashkinov from comment #7)
> What I'm seeing is plain SPAM, e.g.:
> 
> NETFILTER_CFG table=filter family=7 entries=0 op=xt_unregister pid=325361 subj=system_u:system_r:kernel_t:s0 comm="kworker/u8:5"
> NETFILTER_CFG table=filter family=7 entries=0 op=xt_unregister pid=325361 subj=system_u:system_r:kernel_t:s0 comm="kworker/u8:5"
> NETFILTER_CFG table=filter family=7 entries=0 op=xt_unregister pid=325361 subj=system_u:system_r:kernel_t:s0 comm="kworker/u8:5"
> 
> Three identical messages being logged.

They aren't identical if we add the network namspace identifiers (dev/inode).  I already have a patch for that, but is waiting for other work to go upstream.

(In reply to Richard Guy Briggs from comment #8)
> (In reply to Artem S. Tashkinov from comment #7)
> > What I'm seeing is plain SPAM, e.g.:
> > 
> > NETFILTER_CFG table=filter family=7 entries=0 op=xt_unregister pid=325361 subj=system_u:system_r:kernel_t:s0 comm="kworker/u8:5"
> > NETFILTER_CFG table=filter family=7 entries=0 op=xt_unregister pid=325361 subj=system_u:system_r:kernel_t:s0 comm="kworker/u8:5"
> > NETFILTER_CFG table=filter family=7 entries=0 op=xt_unregister pid=325361 subj=system_u:system_r:kernel_t:s0 comm="kworker/u8:5"
> > 
> > Three identical messages being logged.
> 
> They aren't identical if we add the network namspace identifiers (dev/inode).  I already have a patch for that, but is waiting for other work to go upstream.

https://github.com/linux-audit/audit-kernel/issues/79

Artem: A performance issue has been raised in rhel about this same feature, so we'll look at how we can reduce some of the output without losing essential information.  https://bugzilla.redhat.com/show_bug.cgi?id=1921624

Richard,

(In reply to Richard Guy Briggs from comment #8)
> (In reply to Artem S. Tashkinov from comment #7)
> > What I'm seeing is plain SPAM, e.g.:
> > 
> > NETFILTER_CFG table=filter family=7 entries=0 op=xt_unregister pid=325361 subj=system_u:system_r:kernel_t:s0 comm="kworker/u8:5"
> > NETFILTER_CFG table=filter family=7 entries=0 op=xt_unregister pid=325361 subj=system_u:system_r:kernel_t:s0 comm="kworker/u8:5"
> > NETFILTER_CFG table=filter family=7 entries=0 op=xt_unregister pid=325361 subj=system_u:system_r:kernel_t:s0 comm="kworker/u8:5"
> > 
> > Three identical messages being logged.
> 
> They aren't identical if we add the network namspace identifiers
> (dev/inode).  I already have a patch for that, but is waiting for other work
> to go upstream.

Are you sure about that? I see one log message for each element added to a set.
All happening inside the same netns.

Cheers, Phil

(In reply to Phil Sutter from comment #11)
> (In reply to Richard Guy Briggs from comment #8)
> > They aren't identical if we add the network namspace identifiers (dev/inode).  I already have a patch for that, but is waiting for other work to go upstream.
> 
> Are you sure about that? I see one log message for each element added to a set. All happening inside the same netns.

I'm not absolutely sure, but the evidence that some of them definitely are is in the ghak79 link in comment 9.  That said, I would like to work with you to reduce the number of element reports.

2021-03-18 v1 patch posted upstream https://listman.redhat.com/archives/linux-audit/2021-March/msg00109.html
2021-03-22 v2 patch posted upstream https://listman.redhat.com/archives/linux-audit/2021-March/msg00149.html

2021-03-23 v3 patch posted upstream https://listman.redhat.com/archives/linux-audit/2021-March/msg00152.html

v4 posted upstream https://listman.redhat.com/archives/linux-audit/2021-March/msg00157.html

v5 posted upstream  https://listman.redhat.com/archives/linux-audit/2021-March/msg00159.html

2021-03-31 v5 merged upstream in nf-next bb4052e57b5b ("audit: log nftables configuration change events once per table")
2021-03-31 FW found UAF: nf-next fix e4d272948d25 <pablo> ("netfilter: nf_tables: use-after-free")

2021-03-31 v5 merged upstream in nf-next forced update c520292f29b8 ("audit: log nftables configuration change events once per table")

2021-04-02 07:45 Dan Carpenter dadf33c9f6b5 ("netfilter: nftables: fix a warning message in nf_tables_commit_audit_collect()")

This message is a reminder that Fedora 33 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 33 on 2021-11-30.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
Fedora 'version' of '33'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 33 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

This message is a reminder that Fedora 33 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 33 on 2021-11-30.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
Fedora 'version' of '33'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 33 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.