From mboxrd@z Thu Jan 1 00:00:00 1970 From: James Antill Subject: Re: Audit dispatcher process Date: Thu, 11 Jan 2007 14:13:53 -0500 Message-ID: <1168542833.13080.147.camel@code.and.org> References: <1168495131.13080.92.camel@code.and.org> <200701110956.34437.sgrubb@redhat.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0098929150==" Return-path: In-Reply-To: <200701110956.34437.sgrubb@redhat.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: Steve Grubb Cc: linux-audit@redhat.com List-Id: linux-audit@redhat.com --===============0098929150== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-2BLpsp/yL2iOu/FvjRUY" --=-2BLpsp/yL2iOu/FvjRUY Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Thu, 2007-01-11 at 09:56 -0500, Steve Grubb wrote: > So, the receive plugin will need to ack everything its getting and=20 > the senders will need to wait for that ack. Also, need to consider what t= o do=20 > when reboot of the aggregator occurs. Should they spool, if so how much, = etc. This is all contained in the remote plugin, or do you want a general ACK'ing process all the way back to any input plugins. Ie. input plugin =3D> dispatcher =3D> remote logging plugin =3D>=20 remote server =3D> disk "ACK" =3D>=20 remote server <=3D remote logging plugin <=3D -- stop here? -- dispatcher <=3D -- or stop here? -- input plugin <=3D -- or even stop here? -- ...even if we just stop at the remote logging plugin level, are we worried about duplicate entries on the logging server? I guess that's better than missing entries if the power fails on the logging server (I just don't want to have to solve the two generals problem :). > Other requirements: >=20 > plugin installation should be such that they are installed in a way that = does=20 > not require editing the master config file. Perhaps each plugin is requir= ed=20 > to put a config file in /etc/audipsd.d directory which includes at a mini= mum=20 > path to binary and whether or not its enabled (like xinetd). Yeh, I'm meant to say that with the shipped separately point. One thing I'm not sure about is if there's a requirement to pickup new changes/plugins without having to "reboot" the dispatcher in some way. I'd also thought of having the auditd input be a plugin itself, this way you could quickly reboot the dispatcher while the auditd input plugin spooled the incoming data for a small period of time. This might make signal handling simpler too, although it's certainly not in the spirit of the dispatcher :). > Dependencies on external libraries should be kept to a minimum and option= al by=20 > configure options. Well, if by optional you mean "something doesn't get built". Then, yeh, I'd planned to do that ... but I'm not sure how useful it'll be, esp. with regard to any deps needed for the dispatcher itself. > dispatcher interface with auditd has to conform to guidelines here: > http://people.redhat.com/sgrubb/audit/audit-rt-events.txt Ahh thanks, I'd looked at the libaudit.h header and worked out most of the above but the clarification is appreciated. One question though: Should I just take the first 4 bytes, and compare to zero then take the next 12 ... or just grab the first 16, I figured from the .h file that the first 16 will always be there but the above page suggests just checking the first 32 bits (note s/32 bytes/32 bits/ to fix the typo). > config file parsing should use libaudit's parsing code. I'd like to keep = a=20 > consistent style among pieces of the audit system. From what I can see of audit.conf and that code, it would be extremely hard to use for what we'd want to do with plugins. IMO the audit daemon and the dispatcher do very different jobs, so a different config. file syntax isn't a problem, and setroubleshoot already has a totally different config. style. The conf code from And-httpd should be very easy to reuse for this (it's used to configure similar types of applications), already supports conf.d directories, already supports building paths from pieces of dynamic information etc. --=20 James Antill --=-2BLpsp/yL2iOu/FvjRUY Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBFpoxx11eXTEMrxtQRAk2oAJ4rsz5oLjR9pL9+aZMhpM0hcYOVewCfYHpT sFuHY+PF9RF2tDGzDtAigXI= =dYdN -----END PGP SIGNATURE----- --=-2BLpsp/yL2iOu/FvjRUY-- --===============0098929150== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline --===============0098929150==--