Re: Auditing nftables changes

On Thu, Mar 9, 2023 at 11:33 AM Bruce Elrick <bruce.elrick(a)canonical.com&gt; wrote: > > I think I need to clarify where I'm confused ;-) > > With iptables you could write a rule that would only catch system > calls that were for iptables changes. That is, you didn't need to > capture *all* setsockopt calls (not that there would be lots of > *those*) but rather you could add the a2=64 to only get the > op=IPT_SO_SET_REPLACE ones. > > With netfilter, however, since the control interface is netlink and > netlink requires a message to a socket and messages are structs, there > is no way to have a similarly narrow audit rule as in the case of > iptables. > > That's the first thing I want to confirm: whether my understanding > above is correct? Yes, you are correct. > I'm confused because your answer implies I'm correct > but you didn't explicitly confirm that my interpretation of how it > works was correct. > > You talk about having an exclude filter on NETFILTER_CFG (or rather > exclude everything except NETFILTER_CFG??) but my understanding is > that you can only do that filtering after the fact using ausearch or > writing some sort of correlation code using the auparse library. The kernel implements an exclude filter which is described in the auditctl(8) manpage: "Add a rule to the event type exclusion filter list. This list is used to filter events that you do not want to see. For example, if you do not want to see any avc messages, you would using this list to record that. Events can be excluded by process ID, user ID, group ID, login user ID, message type, subject context, or executable name. The action is ignored and uses its default of "never". Taken from https://man7.org/linux/man-pages/man8/auditctl.8.html However, in my last reply I wasn't advocating for this use of the exclude filter, I was simply trying to explain that unless you are explicitly excluding the creation of NETFILTER_CFG records via the exclude filter you should be seeing NETFILTER_CFG in your audit stream with basic auditing enabled.

> It just seemed surprising that there is a non-trivial loss of audit > functionality but that I could not find any obvious discussion about > that. By obvious discussion I mean as explicitly as what I'm trying to > say here. Unfortunately it is a fairly common practice for kernel features to be added, and removed, without consulting with the various Linux Kernel security developers, e.g. audit, SELinux, LSM, etc. Sometimes we are successful in retrofitting the necessary security and/or auditing hooks, sometimes we are limited due to design choices. > The other thing I'm trying to understand is how heavy an audit load > would it be to have an audit rule that captures *all* sendmsg calls > (well, all except where auid=-1 or auid=${serviceuser_uid}). I don't > have a good enough understanding of systems programming to know where > and how often the sendmsg is called. Of course I know this is highly > dependent on workload, but my knowledge is limited enough that I I can > convince myself both that the audit load would be not trivial but > still manageable in most cases but also I can convince myself that no > same sysadmin would consider running such an audit rule. With file IO > it's easy to distinguish that file opens are worth auditing but file > reads and writes would be insane to audit. It's not so clear for me > for sockets. This is going to be dependent on both the workloads and applications used on the system, there is no one "right" answer here. -- paul-moore.com -- Linux-audit mailing list Linux-audit(a)redhat.com https://listman.redhat.com/mailman/listinfo/linux-audit