AUDIT_NETFILTER_PKT message format

[Richard Guy Briggs]

On 2017-02-14 16:31, Steve Grubb wrote:
> On Monday, February 13, 2017 3:50:05 PM EST Richard Guy Briggs 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)? 
> 
> The format for subject attributes would be:
> pid, uid, auid, ses, subj, comm, exe, ...then whatever else you want to add
> 
> This also goes for the netfilter_cfg events.

Ok, this I can deal with.  Thank you.

> > 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?
> 
> If you have this for the majority of events, I'd say leave it unset when you 
> don't. We really don't care about packets that simply transit through the 
> system. Also, I suppose it depends on what kind of packet it is. For example, 
> a icmp echo sent to the machine that is blocked is obviously not going to have 
> an owner. But one originating in the machine heading out should.

I'll add them to the message format and leave them unset if we have no
information.

The way that the AUDIT target is used by users is going to determine
what is the majority of events.  The user has complete freedom to set up
rules such that all of them only log packets transiting the system, but
this is clearly not the intent of this record.

This sounds like it deserves a blog post to clarify the intent and the
limitations and/or an update to the xt_AUDIT manpage.

> -Steve

- RGB

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