From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steve Grubb Subject: Re: Audit dispatcher process Date: Thu, 11 Jan 2007 16:53:54 -0500 Message-ID: <200701111653.54534.sgrubb@redhat.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: Content-Disposition: inline List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: linux-audit@redhat.com Cc: "Todd, Charles" List-Id: linux-audit@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 iss= ued > 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 eva= l.=20 That's why I separated them. But I think the startup code could log plugi= ns=20 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. =A0That is .. > * for 11Jan2007 at 3:46pm would be 20070111154632 > * 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 int= o=20 making the tools tell you what's in each log file. > * 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 ausear= ch. > * 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,=20 presentation, and display. I want to keep the plugins simple and lean. Th= is=20 is to make sure they are reliable. Third party's can go off and write=20 something as complicated as they wish. But whatever is distributed in the= =20 audit package should be simple and robust. > Some internal statistics might be audit buffer ring size, or other usef= ul > 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