Re: Audit dispatcher process

[Steve Grubb <sgrubb@redhat.com>]

On Thursday 11 January 2007 16:03, Todd, Charles wrote:
> I don't know if you want to have signal (of some kind) that must be issued
> in order for a new plugin to take effect.

SIGHUP

> Certainly, the addition of a new plugin should be an audited event, so
> perhaps the CAPP-suggested list automatically includes a write/execute
> watch on this directory.

I have this feeling that the dispatcher may never be a part of a CAPP eval. 
That's why I separated them. But I think the startup code could log plugins 
and changes in config.

> I have a small suggestion for the local logging plugin that will
> probably be put in by default:
> * I recommend a file naming convention similar to that used under
> Solaris.  That is <init_datetime>.<close_datetime>.<host>
> * <init_datetime> for 11Jan2007 at 3:46pm would be 20070111154632
> * <close_datetime> is "not_terminated" when a file is currently being
> written, although this is doesn't work when the dispatcher dies
> prematurely

I'd rather keep the log names simple like it is. I've put some effort into 
making the tools tell you what's in each log file.

> * <host> is usually not the FQDN, but allows lots of audit trail files
> from lots of machines to be in one directory.

I had envisioned 1 unified log. No splitting per machine except by ausearch.

> * Solaris administrators issues a "audit -n" to rotate the logs when
> it's time, and this is occassionally quite handy when archiving logs

this audit system just needs "service auditd rotate"

> * Real-time compression (gzip) is a GREAT idea.

That's in the todo list and targeted around 1.3.3.

> A suggestion I have for the plugin architecture is to allow the plugin
> to query the dispatcher for internal statistics and system call
> number-to-name lookups.

The idea is not to complicate transport and archive with analysis, 
presentation, and display. I want to keep the plugins simple and lean. This 
is to make sure they are reliable. Third party's can go off and write 
something as complicated as they wish. But whatever is distributed in the 
audit package should be simple and robust.

> Some internal statistics might be audit buffer ring size, or other useful
> information to deal with high-load environments.

auditctl -s  ?

> Is the dispatcher responsible for restarting a plugin if the
> process-killer targets it?

Yes. It should keep them alive. Good point.

-Steve