Audit in Kerberos

[Ezra Peisach]

On 1/21/2010 3:04 PM, Zhanna Tsitkova wrote:
> Hello,
> 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.
>
> 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.
>
> 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.
>    
Not all OS's protect the syslog information.  The advantage/disadvantage 
of syslog is that it pushes the info out fast using UDP (I believe) and 
then the syslogd manages it.  Messages can get lost if the disk fills, etc.
>       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.
>    
There are a number of newer databases out there that show better 
performance than the DB we have (tokyocabinet and I think there is 
something newer)
> 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)
>    
I do not personally like xml - but I would not want a binary format.
> 3. Make this feature plugable.
>    
Definite - then you can have the syslog, db, xml, mysql, sqlite, remote 
reporting, etc plugins as needed.

> 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?
>
>    
This is an os issue. If you are using syslogd - O/S vendors have their 
own tools to cleanup the files - do not reinvent the wheel.  On the 
other hand - providing a tool for groveling the logs, send alerts, etc 
periodically would be useful.  But there might be something out there 
that does that already for say an xml structured file (heck I bet nagios 
could do this).  I would say - don't reinvent the wheel there - but if 
there is a standard monitoring program that can be extended - with their 
own plugin system - then write the plugin....  Heck - just googling - I 
found sawmill - which looks nice
> Any feedback and opinions and recommendations are greatly appreciated.
>
>    
In short - give people options w/ plugins - but provide some rudimentary 
backends...

ezra