10:30 a.m.
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?
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?) 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.
Thought I'd mention it if no one hasn't yet.
Mike
BTW, if this isn't in plaintext, let me know, until this point it has been.
10:42 a.m.
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.
It is assumed that when you send the stop...you really mean it. Everything
after that is discarded.
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.
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.
-Steve
2:34 p.m.
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
4:22 p.m.
On Tuesday 14 June 2005 15:34, Michael C Thompson wrote:
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).
Right you need to add a sleep. audit records do not show up instantaneously.
How long it takes could be subject to debate. I'd be more interested in
figuring that out.
As it was explained to me, the way the stop works is when auditd is
told to
"stop", the daemon dies,
Not really. It goes through a series of steps to stop processing and write the
shutdown record. It does not just die.
and any audit messages still in the queue are
"lost" in respect to the log file.
This is true. Stopping the audit daemon is an arbitrary act. You cannot tell
it stop after I get what I want. When you say stop...it has to stop.
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.
Its in the auditd code. No docs.
OK, good point. I remember it being mention during a meeting, but was
there
any further discussion about a "auditd stop" & "auditd shutdown"
option?
No.
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.
How would you know that what you want is already written to disk? If you have
a stream of events coming in non-stop and you have to stop the audit daemon,
you are going to have to cut off at some point. How can you pick any packet
as the last one? They are all equally important. So, the daemon may as well
stop at the instant its told to.
-Steve
4:29 p.m.
Right you need to add a sleep. audit records do not show up
instantaneously.
How long it takes could be subject to debate. I'd be more
interested in
figuring that out.
I'll look into that, maybe we can find an answer, architecture, hardware &
load dependent of course.
> As it was explained to me, the way the stop works is when auditd
is
told to
> "stop", the daemon dies,
Not really. It goes through a series of steps to stop processing andwrite
the
shutdown record. It does not just die.
I think you took it a little too literally, but thats ok. I'll forgive you
this once ;)
> OK, good point. I remember it being mention during a meeting,
but was
there
> any further discussion about a "auditd stop" &
"auditd shutdown"
option?
No.
Deemed unnessecary & therefore pointless to further the debate?
- Mike
4:47 p.m.
On Tuesday 14 June 2005 17:29, you wrote:
> Right you need to add a sleep. audit records do not show up
> instantaneously. How long it takes could be subject to debate. I'd be more
> interested in figuring that out.
I'll look into that, maybe we can find an answer, architecture, hardware &
load dependent of course.
You would almost want to write a program that listens to the netlink socket
just as auditd does, get the time, perform an auditable event, and call
select on the netlink socket. The instant its readable, get the time. It
would be interesting to get a measure of latency.
I think if you want a sure thing, your test will look like this:
auditd start
load rules/watches
perform event
delete rules/watches
monitor backlog until its 0
auditd stop
This should always work with no sleeps.
-Steve
4:28 p.m.
On Tuesday 14 June 2005 15:34, Michael C Thompson wrote:
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).
Something else you can do is poll the backlog.
[root@linux ~]# auditctl -s
AUDIT_STATUS: enabled=1 flag=1 pid=1439 rate_limit=0 backlog_limit=256 lost=0
backlog=0
Will tell you the current backlog. When it goes to 0, everything has been sent
to auditd.
-Steve
7130
days inactive
7130
days old
linux-audit@lists.linux-audit.osci.io
6 comments
2 participants
participants (2)
-
Michael C Thompson -
Steve Grubb