Re: [RFC PATCH] audit: normalize NETFILTER_PKT

On 2017-02-06 14:41, Paul Moore wrote: > On Sat, Feb 4, 2017 at 8:25 AM, Steve Grubb <sgrubb(a)redhat.com&gt; wrote: > > On Friday, February 3, 2017 6:44:16 PM EST Paul Moore wrote: > >> I'm still trying to understand what purpose this record actually > >> serves, and what requirements may exist. In an earlier thread > >> somewhere Steve mentioned some broad requirements around data > >> import/export, and I really wonder if the NETFILTER_PKT record > >> provides anything useful here when it really isn't connecting the > >> traffic to the sender/receiver without a lot of additional logging and > >> post-processing smarts. If you were interested in data import/export > >> I think auditing the socket syscalls would provide a much more useful > >> set of records in the audit log. > > > > The problem here is we cannot be selective enough through the syscall > > interface to get exactly what we want. For example, any auditing of connect > > and accept will also get af_unix traffic which is likely to be uid/gid lookups > > through sssd or glibc. Typically we want the IPv4/6 traffic. The netfilter rules > > are better suited to describing which packets are of interest. > > Okay, but how useful are these NETFILTER_PKT records, really? The > only linkage you have back to the process on the local machine is via > the addr/proto/port tuple and that seems far from ideal. And even that could be spoofed easily and gathering more corroborating information would seem useful. Would the presence of the SOCKADDR record in any SYSCALL record be useful for somehow tagging a class of fd as being of interest?