Audit in Kerberos

[Nicolas Williams]

On Thu, Jan 21, 2010 at 03:04:21PM -0500, Zhanna Tsitkova wrote:
> I would like to re-introduce the idea of extending the  Kerberos  
> security policy by  adding an Audit feature to track the activity on  
> the KDC side.

Solaris has that, though not as full-featured (in terms of KDC events
audited and event-specific data items) as I'd like.  Other operating
systems that MIT krb5 builds on may also have audit subsystems.  Ideally
the MIT krb5 audit facility should be sufficiently simple that it can be
replaced with an OS-specific facility.  I.e., it should be compile-time
pluggable, effectively; the underlying audit system should be run-time
pluggable with respect to audit trail storage, but there should be only
one audit system compiled into the KDC.  See below.

> This would include such events, both successes and failures,  as  
> ticket request, ticket issued/renewed, is ticket forwardable, kdc  
> referral activity,  password modified/expired, constarained delegation  
> (for future) etc.

Yes.

> There are few problems that must be addressed
> 1. Where to store the audit info - in file or DB?
>      Syslog seems to be an attractive option. However, only admin  
> privileged users can access and interpret the log.

Solaris' audit system is pluggable w.r.t. backends.  It has a local
binary audit file format backend, a syslog backend, and a secure remote
backend plugins.  The way we use this audit system from applications in
Solaris varies.  One way is to have audit functions specifically for
individual event types; the arguments to such functions are generally
simple (strings, numbers, but not structure pointers).  Another is to
have functions for constructing event entries, one to start an event,
one for each token in an event, and one to finish the event.  See below.

>      DB log storage suggests more flexibility when  users based on  
> their access rights may review and analyze the accumulated log data.  
> The drawback here is the worsened performance and scalability.

Arguably the audit backend should support on the fly analysis (a la
DTrace) as well as, perhaps, indexing log entries to speed up subsequent
analysis (right now Solaris only supports post-processing of flat binary
audit files).  With a pluggable audit backend system one can actually
build such a thing.

> 2. What format should be used to store the messages. If the messages  
> are stored in the syslog they need to be suitable for db uploading.  
> XML or text? (XML format would result into the rapid file-size growth  
> but , if stored remotely may be not a problem)

IMO this should be up to each audit backend, not up to the application.
Solaris uses a binary scheme and can produce data in various text
formats, including XML.  Solaris audit events are records made up of
tokens of various types.  That model might prove useful here as well as
far as the KDC as an application goes, though I'd discourage you from
writing a generic, re-usable audit facility (the KDC apps will not
provide you with enough experience to design such a thing, plus you'd
likely end up competing with existing audit systems).

If you accept my advice to refrain from building a full-fledged audit
system, then you'll see that the question of what log format to use is
mostly irrelevant (it'd be relevant to a reference audit facility for
the KDC, but for a reference implementation the format doesn't matter
very much).

> 3. Make this feature plugable.

Indeed.

> 4. Some vendors have their own in-house audit mechanisms incorporated  
> in the Kerberos code. Should we introduce our own daemons to  
> monitor,alert, interpret, archive and cleanup or sanitization  of the  
> accumulated log data or should we relay on the OS capabilities?

I think it'd be fine to include a reference audit plug-in (remember,
compile-time pluggable) so you can test KDC auditing.  Where OSes have
public audit interfaces you could make use of them.  Eventually you'll
gain enough implementation experience to produce a more full-featured
audit facility, if that remains desirable.  Sun engineers would replace
MIT's system with one that targets the Solaris audit facility.

Nico
--