Re: AUDIT_NETFILTER_PKT message format

[Richard Guy Briggs <rgb@redhat.com>]

On 2017-02-13 18:50, Paul Moore wrote:
> On Mon, Feb 13, 2017 at 3:50 PM, Richard Guy Briggs <rgb@redhat.com> wrote:
> > On 2017-02-13 12:57, Steve Grubb wrote:
> >> On Friday, February 10, 2017 5:54:45 PM EST Richard Guy Briggs wrote:
> >> > On 2017-02-10 17:39, Steve Grubb wrote:
> >> > > > The alternatives that I currently see are to drop packets for which
> >> > > > there is no local process ownership, or to leave the ownership fields
> >> > > > unset.>
> >> >
> >> > > What ownership fields are we talking about?
> >> >
> >> > The ones you want, auid, pid, ses.  Perhaps I'm using the wrong
> >> > terminology.  What technical term is there for the collection of subject
> >> > identifiers?
> >>
> >> Subject attributes.
> >
> > Ah ok, I'll try to remember to use that term...
> >
> > Now that you know what I'm talking about, can you go back and answer the
> > questions I had about packet "ownership" (which is really packet subject
> > attributes)?  If we have that information, how to we include it in the
> > message format?  And if we don't have it, do we ignore the packet, or do
> > we swing fields out, or do we set those fields to "unset" or do we use
> > an auxiliary record?
> 
> Packet "ownership" is likely going to be impossible to determine
> reliably since in some cases you can't even match a packet to a
> socket, let alone a process.  To back up a few messages in this
> thread, to Richard's list of things to potentially log:
> 
> > helpful         action, hook
> 
> I haven't checked, but do we allow setting of an audit key in
> NETFILTER_PKT records?  It seems like that might be a good thing for
> the userspace tools and would likely make logging the action/hook
> unncessary.

Not that I am aware of.  That would be way useful if it were possible.
"AUDIT" is a netfilter target and you can set the type to "accept",
"drop" or "reject".  Similarly, having the sub-chain name would be
useful but that doesn't appear to be available either.  This is why I
used a "mark" in the testsuite to track packets.

> > useless?        len
> 
> I don't see much point in this.
> 
> > helpful         inif, outif, mark
> 
> Let's split this into two things: the interfaces and the mark.  I
> don't see much value in logging the mark, but I could see some value
> in logging the interface.

In fact, the mark I found to be a useful way to track which rule was
involved and I'd be pretty surprised if others don't try to do the same.

> > useless?        smac, dmac, macproto
> 
> Probably useless in the majority of use cases.

How do we deal with the minority of cases where it could be quite useful?

> > helpful         protocol family
> 
> I think we need some clarity on protocol logging; we've got "macproto"
> (I assume this is the ethertype, or similar), "protocol family" (I
> assume this to be a duplicate of ethertype, e.g. AF_INET), and "proto"
> (see below, I assume this to be TCP/UDP/etc.).

Sorry, you are right.  I know that field as "ethertype" which defines
the "protocol family" (network layer protocol, IPv4/6, etc...).  "proto"
is the transport layer protocol.  For some reason, I was thinking
"macproto" was the link layer type, but that's obvious from the media.

> > useless?        truncated
> 
> Definitely useless.  Only keep this if we need it for some backwards
> compatibility.
> 
> > helpful         saddr, daddr
> 
> Helpful.
> 
> > useless?        ipid
> 
> Useless.
> 
> > helpful         proto
> > helpful         sport, dport
> 
> Assuming "proto" means the TCP/UDP/etc. then we should treat the
> proto/ports as one block; you can't log the ports without logging
> "proto".
> 
> > useless?        frag
> > useless?        truncated
> 
> Yes, useless.
> 
> > helpful         icmptype, icmpcode
> 
> Similar to proto/port above.
> 
> > helpful         secmark (I forgot to change it from "obj" to "secmark" in my patch).
> 
> We may also want to log the peer label if we are going to log the secmark.

Ok, noted.

> paul moore

- RGB

--
Richard Guy Briggs <rgb@redhat.com>
Kernel Security Engineering, Base Operating Systems, Red Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635