Audit log Fields

[Steve Grubb]

On Friday, February 12, 2016 12:06:54 AM Burn Alting wrote:
> Steve,
> 
> Perhaps we could update the above document to advise users what they
> should offer in such a proposal.

Good point. Usually they come to the list and say I am working on a daemon 
that needs to write something to the audit log whenever this kind of thing 
happens. How should I record it.

This leads to a better conversation because not everything is a candidate for 
the audit logs. That doesn't mean it doesn't need to be recorded, it just 
means it needs to go somewhere else.

For example, tcp_wrappers can reject connections. Should that go into audit 
logs automatically? No way. Same with web application access control. These 
are important enough to be logged, but they belong in an application log.


> Perhaps further, we could offer a generic solution on how one could
> define a 'non-public' field name. That is, a 'non-public' field is one
> which could not, via it's nomenclature, conflict with a current or
> future 'public' (aka published) field name. Such non-public fields could
> then be used by capability that only needs the audit source and audit
> consumer to be aware of the field.

That's a good point. I'm pretty sure 'private-' will never be used for a prefix 
to any field. That said, if this is going into an existing event, we really 
need to have a discussion about that. This affects all third party's that try 
to make sense of the audit logs,

-Steve