[RFC PATCH] audit: normalize NETFILTER_PKT

[Paul Moore]

On Tue, Feb 7, 2017 at 4:22 PM, Richard Guy Briggs <rgb at redhat.com> wrote:
> On 2017-02-06 14:41, Paul Moore wrote:
>> On Sat, Feb 4, 2017 at 8:25 AM, Steve Grubb <sgrubb at redhat.com> 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