KDC Audit project

[Nico Williams]

On Tue, Jan 8, 2013 at 10:48 AM, Benjamin Kaduk <kaduk at mit.edu> wrote:
> With one-interface-per-event, the plugin knows exactly what it has to do
> with the data, there is no room for ambiguity and no need to attempt a
> possibly-incorrect "best effort" treatment of unknown data.

Indeed.  This is nice.  However, pre-auth and other such plugins too
may want to audit (well, maybe), and since those are plugins, there's
no way that the audit subsystem can provide the non-generic
functionality that they will need.

My suggestion is: a) have a generic core that takes arrays of
arbitrary (typed) values or dicts with string keys and arbitrary
(typed) values, then JSON-encode the thing, b) provide built-in
event-specific interfaces for all internal purposes.

Now, I may be exaggerating.  There may well be no reason for external
plugins to audit in success cases (but I wouldn't agree).  There will
be a need to audit in failure cases, but you might suggest that a
simple string is all that's needed from a pre-auth or authz-data
plugin (but I wouldn't agree).

IMO you will want interesting pre-auth and other data to be preserved
in a structured way.  It's not just "cname at realm got an INITIAL TGT
with ..." that I would want to see, but "cname at crealm preauthenticated
successfully with X pre-auth (<pre-auth-specific data>) got ..." (and,
of course, I want the JSON or similar equivalent of that).

Another question is whether pre-auth and such plugins get to audit
separate events (IMO: no) or merely provide structured data to be
added to an audit record (IMO: yes).

Also, there may be third-party libkadm5srv apps (there are!) that may
want to emit audit records for operations composed of more than one
kadm5 operation.  Should not such apps also get to emit audit records
for their logical events?!  IMO: resoundingly yes.  Of course, it'd
help if libkadm5srv had some notion of transactions (even if not
ACID), in which case the libkadm5srv app could provide its structured
data to add to a single audit record emitted by libkadm5srv -- but
hey, that's asking for a lot, so I'd settle for a generic audit API.

ALL of that said, if someone wanted to write an audit plugin that
converts to some other facility that is not generic, then they'd have
a lot of interpretation to do.  But I don't think that's a very big
deal.  What would happen in that case is that the non-generic audit
functions would call directly into their equivalents as provided by
the plugin and structured data from other plugins gets dropped (by the
audit plugin).

Nico
--