On Tue, Feb 7, 2017 at 4:22 PM, Richard Guy Briggs <rgb@xxxxxxxxxx> wrote: > On 2017-02-06 14:41, Paul Moore wrote: >> On Sat, Feb 4, 2017 at 8:25 AM, Steve Grubb <sgrubb@xxxxxxxxxx> 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? I don't think we want to create a SOCKADDR record for every syscall, but it seems reasonable that we may want to include it for targeted syscalls. Right now it looks like we create a SOCKADDR record whenever we copy a sockaddr struct across the kernel/userspace boundary, that should be sufficient, yes? -- paul moore security @ redhat -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
