KDC Audit project

[Nico Williams]

On Tue, Jan 8, 2013 at 6:58 PM, Dmitri Pal <dpal at redhat.com> wrote:
> Adding data to the event or adding a new event with similar data but in
> a different part of the code is not a rare use case.

+1.

Audit records should (must!) be structured data with extensible
schemas.  If the schema is extended backwards compatibly, any older
consumers should still be able to consume the new records.

Imagine a Unix audit system that includes UID, GID, and supplementary
GIDs in a login record, and later the OS gains support for labels, and
later for SIDs, and so on: the login record had better be able to
include those things!  (Arguably such a change would be semantically
backwards-incompatible since old consumers of a login message should
understand the implications of labels, but let's set that aside for
now.)  Shouldn't such a change be feasible without losing data nor
breaking old consumers?

The same applies to Kerberos.  If MIT Kerberos had had audit code in
it eons ago, with the pre-auth plugin facility coming much later,
wouldn't one want new pre-auth additional data to be included in new
records of existing types [that involve pre-auth]?  Surely the answer
would be "yes!".  We can't have certainty that no new such cases will
come up in the future.  So please, make the audit facility be all
about structured data.

And please emit minimal JSON encoding of data.  You have some
Heimdal-derived code for this already, IIRC.

Nico
--