auditd stop suggestion

[Michael C Thompson]

> On Tuesday 14 June 2005 11:30, Michael C Thompson wrote:
> > I was wondering, based on the amounts of sleeps we are needed to put
into
> > our test cases (and this might already have been said, if so, keep the
> > flames to a low simmer) is there some way to change auditd stop to have
it
> > capture all of the messages up until the point where the stop was
issued?
>
> It does capture all the events up to the point the stop was issued.
However,
> the stop and the messages travel in 2 different paths. One is a signal
which
> entirely avoids the queue.

Alright, I'm not sure if I made my point clearly (or perhaps I am
misundersanding yours), what is happening with our test cases is the
following:

system("/etc/rc.d/init.d/auditd start");
...
TEST(syscall(..))
...
system("/etc/rc.d/init.d/auditd stop");

Now, the outter portion of the code here (that is, before the start, and
after the stop) should not be affecting the actions taken between start and
stop (seems obviously correct, could be wrong). The issue we're
experiencing is that when the stop is called, the audit.log file has no
trace of what has transpired between the "start" & "stop" auditd calls.
However, without putting sleeps (e.g. sleep(2); seems to be the most
effective) before we call "../auditd stop" then the records in file which
we are hoping to verify with are not there, unless we prolong the stop
(i.e. with a sleep).

As it was explained to me, the way the stop works is when auditd is told to
"stop", the daemon dies, and any audit messages still in the queue are
"lost" in respect to the log file. If you could confirm that, or point me
to a place where that's documented and I'll read it for my self, it would
help me to understand the behaviour better.


> It is assumed that when you send the stop...you really mean it.
Everything
> after that is discarded.

Which makes sense, no issue there...


> > Seems to me that while this change doesn't have to come now, it would
be a
> > nice addition in the future. Perhaps having the auditd stop insert a
> > message into the queue (if thats possible?)
>
> We talked about this at length. What if the new event causes a kernel
panic
> due to backlog overflow? Or what if they don't have failure set to panic,
the
> audit daemon is waiting for a record that will never be sent. If a
shutdown
> is occurring, you won't have the audit stop message.

OK, good point. I remember it being mention during a meeting, but was there
any further discussion about a "auditd stop" & "auditd shutdown" option? I
know it was in regards to clearing the specified rules, but it seems it
could be associated with this. Inserting a message into the queue might not
be the best solution for the afore stated reasons, and while I don't have
any ideas right now, doesn't mean there isn't an answer.


> > and have auditd die when it seems that message, as opposed to just
dropping
> > dead when the stop is made, causing a possible (and highly probable,
happens
> > all the time with our  tests if they don't have sleeps) loss of
information.
>
> You are in the unique position of expecting something in the logs.
> In the real
> world use, the machine is going down and you need to finish up asap or
not
> audit stop message will get written.

Right, the tests we are running are not a good indicator of the way
auditd's running status will be treated in a real environment, but there
must be some valid reasons for stopping auditd outside of a shutdown in a
real environment, which would still have this queue issue. Of course, while
auditd is down, there is 0 chance at logging anything, so it could just be
a moot point.

- Mike
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/linux-audit/attachments/20050614/8bc7f43d/attachment.htm>