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

[Paul Moore]

On Wednesday, October 22, 2014 01:56:13 PM Steve Grubb wrote:
> 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");

In my mind the latter code is more robust and preferable.

> 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.

What about the speed and performance of the code in the kernel?  What about 
the maintenance burden of having to duplicate code to ensure a fixed format?

I'm sorry, I don't find your argument above to be compelling.

> > 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.

It has worked.  It is causing problems now, and these issues will likely only 
increase as things progress.

> 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.

In summary, code needs to be reviewed; I think we all agree on that.

> > > > 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.

I disagree about the priority.  Eric disagrees about the priority.  Richard 
hasn't explicitly stated he disagrees with the priority but he has made 
several comments on this list about ordering being an issue (Richard, my 
apologies if I am putting words in your mouth).

Does the audit userspace still live in SVN on fedorahosted.org?  What would we 
need to change in the userspace to eliminate the reliance on field ordering?  
I understand if you don't have a well developed list of items, but surely you 
must have some idea?

I'm willing to help here, and I suspect there might be some others as well, 
just let us know what the pressing issues are in the audit userspace.

> 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.

... and the field ordering issue is swept under the run again.  I feel this is 
an important issue and we should deal with it now; it will only be harder to 
resolve later.

> > 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.

We're seeing at least one case where our inability to change the ordering of 
the audit fields is causing problems.

> > > 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.

Eric, do you have one published somewhere?

Assuming that Eric doesn't have a TODO list posted somewhere, do you have any 
objections to my posting and maintaining an audit kernel TODO list on the 
audit fedorahosted.org wiki?

-- 
paul moore
security and virtualization @ redhat