KDC Audit project

[Dmitri Pal]

On 01/08/2013 07:57 PM, Nico Williams wrote:
> 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.

Yes this is what I proposed too though I would see the generic interface
as a core and then instead of the event specific functions helper
functions that provide a predefined common subset that can be extended
as needed.
See the elapi interface and it is wiki pages. There was a lot of
thinking put into how to do all this.
https://fedorahosted.org/ELAPI/wiki/WikiPage/Architecture

Here are the headers and example:
https://fedorahosted.org/ELAPI/browser/elapi_event.h <- construct an
event or event template out of data
https://fedorahosted.org/ELAPI/browser/elapi_log.h <- log event or KVPs
https://fedorahosted.org/ELAPI/browser/elapi_ut.c <- unit test and a
good example of use at the same time

This is the kind of interface I am talking about.


>
> Now, I may be exaggerating.  There may well be no reason for external
> plugins to audit in success cases (but I wouldn't agree). 

I would not agree with this.

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

Simple string is one of the results how plugin can record data. But its
input should be structured so that plugin can be replaced with the one
that passes structured data on.
>
> 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).

Yes JSON seems like a good option.
However it would require encoding and decoding on the interface boundary.
IMO it should be OK to use a list, collection or hash table to avoid
this serialization. There are stable libraries that provide those basic
primitives and event concept can be wrapped around them.
ELAPI uses libcollection which is pretty stable but some other primitive
would be fine too. IMO this part can be easily forked if there are
concerns about dependencies. These primitives do not change so it would
not affect plugins.

 

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

Different auth mechanisms will have different subsets of data in
different code paths. So notion of the data sets is the right approach.
It really does not matter what the source is as long as you can log any
set of data
>
> 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).

Yes, sort of implicit filtering.

>
> Nico
> --


-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager for IdM portfolio
Red Hat Inc.


-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/