On 2017-02-07 23:02, Paul Moore wrote: > 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? Yes, we certainly don't need it for every syscall. Since the sockaddr record is only created if it is available we could further flag or check the protocol to further process only the network-based sockaddrs and ignore the unix sockaddrs for this purpose. I'm picturing adding a flag to the fd, but that is making me a bit nervous about overstepping our usual code area. > paul moore - RGB -- Richard Guy Briggs <rgb@xxxxxxxxxx> Kernel Security Engineering, Base Operating Systems, Red Hat Remote, Ottawa, Canada Voice: +1.647.777.2635, Internal: (81) 32635 -- 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
