Re: [RFC][PATCH] audit: log join and part events to the read-only multicast log socket
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