audit-1.7.16 released

audit-1.7.16 released

[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 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

Re: audit-1.7.16 released

[LC Bruzenak]

On Sat, 2009-10-17 at 11:55 -0400, Steve Grubb wrote:
> 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

Is there any indication that this event has happened being logged?
The man page indicates it might be ("...before auditd complains").

Thx,
LCB.

-- 
LC (Lenny) Bruzenak
lenny@magitekltd.com

Re: audit-1.7.16 released

[Steve Grubb]

On Monday 26 October 2009 10:46:33 am LC Bruzenak wrote:
> On Sat, 2009-10-17 at 11:55 -0400, Steve Grubb wrote:
> > 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.
> 
> 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

Re: audit-1.7.16 released

[LC Bruzenak]

On Fri, 2009-10-30 at 10:56 -0400, Steve Grubb wrote:
> 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

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.

-- 
LC (Lenny) Bruzenak
lenny@magitekltd.com

Re: audit-1.7.16 released

[Steve Grubb]

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.

-Steve

Re: audit-1.7.16 released

[LC Bruzenak]

On Mon, Nov 16, 2009 at 9:59 AM, Steve Grubb <sgrubb@redhat.com> wrote:
> 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.

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!).

>
>> 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.

-- 
LC (Lenny) Bruzenak

Re: audit-1.7.16 released

[Steve Grubb]

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

Re: audit-1.7.16 released

[LC Bruzenak]

On Tue, Nov 17, 2009 at 3:48 PM, Steve Grubb <sgrubb@redhat.com> wrote:
> 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
>

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.

-- 
LC (Lenny) Bruzenak

Re: audit-1.7.16 released

[LC Bruzenak]

On Tue, Nov 17, 2009 at 9:52 PM, LC Bruzenak <lenny@magitekltd.com> wrote:
> On Tue, Nov 17, 2009 at 3:48 PM, Steve Grubb <sgrubb@redhat.com> wrote:
>> 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
>>
>
> 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.

-- 
LC (Lenny) Bruzenak