audit-1.7.16 released
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
Quoted 17 lines · Steve Grubb
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 downThis 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.
Quoted 3 lines
Please let me know if you run across any problems with this release.
-Steve
Is there any indication that this event has happened being logged? The man page indicates it might be ("...before auditd complains").
Thx,
LCB.
Signature · 2 lines
LC (Lenny) Bruzenak [email protected]
Quoted 18 lines · LC Bruzenak
Quoted 17 lines · Steve Grubb
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 downThis 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.
Quoted 3 lines
Quoted 1 line
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
Quoted 19 lines · Steve Grubb
Quoted 1 line · LC Bruzenak
On Sat, 2009-10-17 at 11:55 -0400, Steve Grubb wrote:
...
Quoted 16 lines
Quoted 15 lines
- 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 downThis 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.
Quoted 7 lines
Quoted 1 line
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
Steve,
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.
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. For me, the connection termination is a good indication, so I will probably patch mine.
I wonder if it would be helpful for others as well.
Thx,
LCB.
Signature · 2 lines
LC (Lenny) Bruzenak [email protected]
Quoted 4 lines · LC Bruzenak
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.
Quoted 3 lines
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.
-Steve
Quoted 11 lines · Steve Grubb
Quoted 4 lines · LC Bruzenak
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.
And for most systems I agree. For me, if a switch fails and I get 4000 events that is acceptable.
Actually, on my systems, if a switch dies the clients will all start shutting down. Then after it is fixed, and they reboot, they will resend their events the way you suggested - by grabbing all of them from the estimated network send error time and push them into audisp-remote (BTW works great; thanks!).
Quoted 9 lines
Quoted 4 lines
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.
I am not getting the DAEMON_END events. In an orderly shutdown, the network shuts down before the audit daemon does. In a catastrophic or otherwise unintended termination, obviously there it would be of benefit.
Thx,
LCB.
Signature · 1 line
LC (Lenny) Bruzenak
Quoted 6 lines · LC Bruzenak
Quoted 3 lines
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_ENDevents. 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
Quoted 5 lines · Steve Grubb
Quoted 4 lines · LC Bruzenak
Quoted 3 lines
You should have daemon start/end events at the aggregator. Are they not getting there? Also, the aggregator should have matching connect/disconnect events.
Quoted 8 lines
Quoted 2 lines
I am not getting the
DAEMON_ENDevents. 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
Thanks, that would help in the case where the client shuts down normally. There is definitely utility in having a positive event come from the sender saying it is shutting down.
But if the client gets the power cord yanked out it doesn't help me, so I'll still try to add something on the server side to add a local audit event as well as the syslog.
Thx,
LCB.
Signature · 1 line
LC (Lenny) Bruzenak
Quoted 15 lines · LC Bruzenak
Quoted 5 lines · Steve Grubb
Quoted 4 lines · LC Bruzenak
Quoted 3 lines
You should have daemon start/end events at the aggregator. Are they not getting there? Also, the aggregator should have matching connect/disconnect events.
Quoted 8 lines
Quoted 2 lines
I am not getting the
DAEMON_ENDevents. 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
Quoted 8 lines
Thanks, that would help in the case where the client shuts down normally. There is definitely utility in having a positive event come from the sender saying it is shutting down.
But if the client gets the power cord yanked out it doesn't help me, so I'll still try to add something on the server side to add a local audit event as well as the syslog.
OK, I see it appears it would work as expected.
I see that the "close_client" gets called on a client timeout, and it does send a AUDIT_DAEMON_CLOSE event. I will test that ASAP. I assume a client which just drops off would hit this case.
Thx!
LCB.
Signature · 1 line
LC (Lenny) Bruzenak