2:32 p.m.
Hi,
I found that when I stop auditd, any existing audit rules still exist, but
they are
deleted when I restart using audit-0.6.2. Is this new behavior deliberate
and
preferred? Is there a new option to not delete rules on startup? All our
tests
are stopping and restarting auditd between assertions and cleaning out the
log file to reduce clutter. We'll need to change the tests if this will no
longer
work. If users have a lot of rules created but have to bring down auditd
for
some reason, won't this be a problem?
Thanks!
Kris Wilson
Linux Security
(512) 838-0126 T/L:678-0126
krisw(a)us.ibm.com
2:49 p.m.
On Mon, 14 Feb 2005 14:32:36 CST, Kris Wilson said:
I found that when I stop auditd, any existing audit rules still
exist, but
they are
deleted when I restart using audit-0.6.2. Is this new behavior deliberate
and
preferred? Is there a new option to not delete rules on startup? All our
tests
are stopping and restarting auditd between assertions and cleaning out the
log file to reduce clutter. We'll need to change the tests if this will no
longer
work. If users have a lot of rules created but have to bring down auditd
for
some reason, won't this be a problem?
List the rules in /etc/audit.rules (new file added in 0.6.2)....
8:10 a.m.
On Monday 14 February 2005 15:32, Kris Wilson wrote:
I found that when I stop auditd, any existing audit rules still
exist, but
they are deleted when I restart using audit-0.6.2. Is this new behavior
deliberate and preferred?
Yes. It wasn't done with your test suite in mind, but as a first round attempt
to solve real production server issues. The preferred way to "reload" rules
is:
service auditd restart
This means that it terminates the audit daemon, re-runs it, deletes the rules
and reloads the rules. I'm still looking this over and may tweak it some more
in the next release. I may make a "reload" target that doesn't stop the
daemon, but just reloads the auditctl rules.
I'm not sure a sighup makes sense for this daemon. I'd have to re-architect
some of it to stop the logging thread and make a new logging thread with new
config data. I plan to revisit this issue down the road after seeing how the
current version works out.
Is there a new option to not delete rules on startup?
No.
All our tests are stopping and restarting auditd between assertions
and
cleaning out the log file to reduce clutter. We'll need to change the tests
if this will no longer work.
What I would suggest is commenting out the -D at the top of /etc/audit.rules.
Or maybe you want many different audit.rules files and your test script swaps
out the file between "runs".
Thanks,
-Steve Grubb
10:07 a.m.
--- Steve Grubb <sgrubb(a)redhat.com> wrote:
I'm not sure a sighup makes sense for this daemon.
The technical difficulties aside, it is
very useful in just about any environment
to have the abilty to goose the audit daemon.
The use of the audit trail as a validation
scheme is hugely valuable. You should go out
of your way to support it if you want the
audit trail to be widely adopted. None of
the Irix evaluations would have gotten finished
had we been unable to SIGHUP the audit daemon.
In production environments shutting down and
restarting audit is just not an option. You need
a way to refresh the audit characteristics
on the fly.
=====
Casey Schaufler
casey(a)schaufler-ca.com
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
7249
days inactive
7250
days old
linux-audit@lists.linux-audit.osci.io
3 comments
4 participants
participants (4)
-
Casey Schaufler -
Kris Wilson -
Steve Grubb -
Valdis.Kletnieks＠vt.edu