Hi, I've just released a new version of the audit daemon. It can be downloaded from http://people.redhat.com/sgrubb/audit. It will also be in rawhide soon. The ChangeLog is: - If audisp-remote plugin has a queue at exit, use non-zero exit code - In auditd, tell libev to stop processing a connection when idle timeout - In auditd, tell libev to stop processing a connection when shutting down This release fixes a bug introduced in the 1.7.15 release. The main problem was that the idle timeout was not telling libev to stop processing the associated socket when it closed an idle connection. Subsequent reconnects would go into an error state and libev would immediately close the new connection. This update fixes that problem. I also applied a patch from trunk that checks the queue size on exit of audisp-remote to decide if it was successful or not. Please let me know if you run across any problems with this release. -Steve

On Monday 26 October 2009 10:46:33 am LC Bruzenak wrote: > On Sat, 2009-10-17 at 11:55 -0400, Steve Grubb wrote: ... > > > > - If audisp-remote plugin has a queue at exit, use non-zero exit code > > - In auditd, tell libev to stop processing a connection when idle timeout > > - In auditd, tell libev to stop processing a connection when shutting > > down > > > > This release fixes a bug introduced in the 1.7.15 release. The main > > problem was that the idle timeout was not telling libev to stop > > processing the associated socket when it closed an idle connection. > > Subsequent reconnects would go into an error state and libev would > > immediately close the new connection. This update fixes that problem. I > > also applied a patch from trunk that checks the queue size on exit of > > audisp-remote to decide if it was successful or not. > > > > Please let me know if you run across any problems with this release. > > Is there any indication that this event has happened being logged? This was a bugfix where libev was not being told that the connection was closed by the auditd code. The fix is right below the syslog message saying this happened. -Steve

On Friday 13 November 2009 08:14:22 pm LC Bruzenak wrote: > Thinking about the client network connection timeout... > > I am wondering if this is a serious enough condition to warrant > inserting an audit event in addition to the syslog. If you have 1000 machines and the switch dies, you will have 4000 events when everything reconnects. The server will record its own events and the clients will record duplicate copies from their end. The audit trail has not been lost or anything bad happened. I think this is more of a systems management issue than security.

> For me it is, because sending a termination event from the client is > both difficult and unreliable, and I am supposed to provide client > (sender) startup/shutdown data. You should have daemon start/end events at the aggregator. Are they not getting there? Also, the aggregator should have matching connect/disconnect events.

On Monday 16 November 2009 06:52:24 pm LC Bruzenak wrote: > > You should have daemon start/end events at the aggregator. Are they not > > getting there? Also, the aggregator should have matching > > connect/disconnect events. > > I am not getting the DAEMON_END events. In an orderly shutdown, the > network shuts down before the audit daemon does. OK, I'll take a look to see if things can be reordered to let this event get sent. -Steve