[RFC][PATCH] audit: log join and part events to the read-only multicast log socket

[Steve Grubb]

On Wednesday, October 22, 2014 11:28:46 AM Paul Moore wrote:
> On Wednesday, October 22, 2014 10:25:35 AM Steve Grubb wrote:
> > On Tuesday, October 21, 2014 06:30:24 PM Paul Moore wrote:
> > > This is getting back to my earlier concerns/questions about field
> > > ordering, or at the very least I'm going to hijack this conversation and
> > > steer it towards field ordering ;)
> > 
> > Field ordering is important. For example, suppose we decide to make
> > ordering changes to the AUDIT_AVC record to bring it in line with current
> > standards. Would anyone care?
> 
> That is an interesting example record considering everyone recognizes it to
> be an oddly formed, special case.

But it illustrates the point. There are tools that depend on an ordering and 
format. There are more programs that just ausearch that needs to be considered 
if the fields change. For example, Someone could do things like this:

retval = auparse_find_field(au, "auid");
retval = auparse_next_field(au);
retval = auparse_next_field(au);
retval = auparse_find_field(au, res");

Where, if the field ordering can't be guaranteed, the code becomes:

retval = auparse_find_field(au, "auid");
retval = auparse_first_field(au);
retval = auparse_find_field(au, "pid");
retval = auparse_first_field(au);
retval = auparse_find_field(au, "uid");
retval = auparse_first_field(au);
retval = auparse_find_field(au, res");

Which of the two is likely to be faster? Especially when doing realtime 
analysis as a plugin and needing to finish because another event is coming in? 
Just like a binary struct has to maintain an order of data members if written 
to disk, the sequence of fields need to be maintained in a text record.


> I'd like to discuss improving the AVC
> audit record, but that discussion is lower priority than the field ordering
> discussion.
> 
> Let's stick to correctly formed audit records that follow the name-value
> pair format perfectly; I argue that while we may get accustomed to a
> specific field ordering, the field ordering for well formed audit records
> should not be guaranteed.

Its worked well for the 10 years I've been working on the audit code. There 
has to be a review cycle when any new events are created.  People generally 
make up field names without looking at the catalogue, they use an already 
assigned name for something different, they put them in the wrong order, they 
have dangling words instead of following name=value, they use the wrong event 
type, they might not put enough information in the event, or they put fields in 
the wrong order. All these issues are caught and fixed by review.


> > > Before we go to much farther, I'd really like us to agree that ordering
> > > is
> > > not important, can we do that?
> > 
> > Its kind of doubtful we can do anything like this quickly. Maybe over
> > time.
> 
> Why?  Why can we not do this now?

There are more pressing needs on the user space side of this. reordering fields 
means I have to drop all my current plans and redo something that's been 
working fine. This is why it takes so long to get audit utilities and reports 
that are fast, understandable, and the right information.

The problem at hand is Richard wants to make 2 new events. He wants to know 
what goes in them. We can make a function that pulls the right information 
together and add it to his new event. The immediate problem is solved.


> What, besides some assumptions by the
> userspace tools, is preventing us from fixing this?
> 
> > But for entirely new events, we can create some canonical order and use
> > it.
> 
> No.  Field order is a problem, not a feature we need to promote.
> 
> > > As a follow up, what do we need to do to make that happen in the
> > > userspace
> > > tools?
> > 
> > I have serious doubts that this is worth doing right now.
> 
> I disagree.  I think we need to resolve this before we go forward with
> adding, or modifying any audit records.

We shouldn't be doing much modifying of records. They really should be pretty 
static unless requirements change. For new records, there is no guarantee that 
the function created before is the right information for the new event. It 
just depends on what it is as to what needs to be collected. Then due to all 
the misused fields, we still need to have review to make sure there's no typo. 
Speaking of which, I just found a typo in 
AUDIT_FEATURE_CHANGE events.
 

> > To me, these are the burning issues that I think should be on the table to
> > be solved rather than field ordering:
> > 
> > 1) ... {snip} ...
> 
> Ignoring the priority for a moment, thanks for posting these.  Is there an
> audit TODO list posted somewhere?

That is just some kernel issues off the top of my head. Things come up all the 
time. Most of the time things are found because someone is asking questions or 
I am trying to make sense of the audit trail.

As for user space tools, yes there is a TODO file in the audit tarball. I don't 
know if the kernel maintainers have a TODO list published anywhere.

-Steve