On 2017-02-08 18:11, Paul Moore wrote:
On Wed, Feb 8, 2017 at 7:32 AM, Richard Guy Briggs
<rgb(a)redhat.com> wrote:
> On 2017-02-07 23:02, Paul Moore wrote:
>> On Tue, Feb 7, 2017 at 4:22 PM, Richard Guy Briggs <rgb(a)redhat.com>
wrote:
>> > On 2017-02-06 14:41, Paul Moore wrote:
>> >> On Sat, Feb 4, 2017 at 8:25 AM, Steve Grubb <sgrubb(a)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?
>
> 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(a)redhat.com>
Kernel Security Engineering, Base Operating Systems, Red Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635