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

[Paul Moore]

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

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

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

-- 
paul moore
security and virtualization @ redhat