On 2017-02-08 18:11, Paul Moore wrote: > On Wed, Feb 8, 2017 at 7:32 AM, Richard Guy Briggs <rgb@xxxxxxxxxx> wrote: > > 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. > > Let's keep it as-is, I would think there are other cases where having > the address info for AF_UNIX (and others) might be helpful. I wasn't suggesting removing the existing AUDIT_SOCKADDR support for AF_UNIX or other types of sockets, but rather when they are encountered by the audit subsystem flag the fd (if it isn't already identified as a network socket) as having more interesting information for network auditing. > 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
