All of lore.kernel.org
 help / color / mirror / Atom feed
From: LC Bruzenak <lenny@magitekltd.com>
To: Steve Grubb <sgrubb@redhat.com>
Cc: Linux Audit <linux-audit@redhat.com>
Subject: Re: audit-1.7.16 released
Date: Fri, 13 Nov 2009 19:14:22 -0600	[thread overview]
Message-ID: <1258161262.5355.214.camel@lcb> (raw)
In-Reply-To: <200910301056.20700.sgrubb@redhat.com>

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

  reply	other threads:[~2009-11-14  1:14 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-10-17 15:55 audit-1.7.16 released Steve Grubb
2009-10-26 14:46 ` LC Bruzenak
2009-10-30 14:56   ` Steve Grubb
2009-11-14  1:14     ` LC Bruzenak [this message]
2009-11-16 15:59       ` Steve Grubb
2009-11-16 23:52         ` LC Bruzenak
2009-11-17 21:48           ` Steve Grubb
2009-11-18  3:52             ` LC Bruzenak
2009-11-18  4:16               ` LC Bruzenak

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1258161262.5355.214.camel@lcb \
    --to=lenny@magitekltd.com \
    --cc=linux-audit@redhat.com \
    --cc=sgrubb@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.