aggregation/viewer question
by LC Bruzenak
Has anyone been thinking about how to store/maintain the aggregated
audit data long-term?
In my setup, I will be sending data from several machines to one central
log host.
After a while, the number of logs/data will grow large. With hundreds of
files, the rotate will take more time and the audit-viewer "select
source" option becomes tedious. Most of my searches involve
time/host/user. Using the prelude plugin helps a lot, because it
highlights what is otherwise hidden in the data pool. But pulling out
that record from a selection of log files isn't currently intuitive.
I would think we'd put these into a RDB or structure them by time
directory structure something like year/month/week ... or maybe
something else entirely. I'm thinking also about ease of backup/restore
with incoming records. I'd hate to shut down all the sending clients
just to backup or restore my audit data, so that part will need to
operate asynchronously.
Before striking out on my own I thought I'd ask the list and see if
there are any such plans already in the works.
As a suggestion, the prewikka viewer seems like a workable model. I
realize that viewer is built around the IDS structure, but as an event
search tool it is pretty good and mostly complete. Having network access
to it is also a nice feature.
So right now I think that feeding the events into a DB and then using a
tool with the same capabilities as are in the prewikka viewer would be a
viable option. Others? Ideas?
Thanks in advance,
LCB.
--
LC (Lenny) Bruzenak
lenny(a)magitekltd.com
17 years
auditing file based capabilities
by Steve Grubb
Hi,
With file based capabilities in recent kernels, I think we need to add those
to the path records. An example PATH record:
node=127.0.0.1 type=PATH msg=audit(1223893548.459:459): item=1
name="/etc/resolv.conf" inode=20774937 dev=08:08 mode=0100644 ouid=0 ogid=0
rdev=00:00 obj=system_u:object_r:net_conf_t:s0
If executing the file leads to extra capabilities, I think we need to record
that. If we add it, I'd like to see it recorded like render_cap_t does for
the proc filesystem. In order to conserve disk space, should we make the
field optional so that it doesn't appear in the record unless there are file
based capabilities?
Thanks,
-Steve
17 years
restorecon resets files
by LC Bruzenak
# ls -Z /var/run/auditd.pid /var/run/audispd_events
srw-r----- root root system_u:object_r:audisp_var_run_t:SystemHigh /var/run/audispd_events
-rw-r--r-- root root system_u:object_r:auditd_var_run_t:SystemHigh /var/run/auditd.pid
# restorecon -rv /var/run/
restorecon reset /var/run/audispd_events context system_u:object_r:audisp_var_run_t:s15:c0.c1023->system_u:object_r:audisp_var_run_t:s0
restorecon reset /var/run/auditd.pid context system_u:object_r:auditd_var_run_t:s15:c0.c1023->system_u:object_r:auditd_var_run_t:s0
[root@hugo ~]# ls -Z /var/run/auditd.pid /var/run/audispd_events
srw-r----- root root system_u:object_r:audisp_var_run_t:SystemLow /var/run/audispd_events
-rw-r--r-- root root system_u:object_r:auditd_var_run_t:SystemLow /var/run/auditd.pid
I assume that both these files should be kept at SystemHigh?
selinux-policy-mls-3.4.2-14.fc9.noarch
Thx,
LCB.
--
LC (Lenny) Bruzenak
lenny(a)magitekltd.com
17 years
DWIM audit tools
by Matthew Booth
Has anybody been looking at making writing audit rules a bit more DWIM.
E.g. when the user types:
auditctl -a entry,always -S stat
what they almost certainly meant was:
auditctl -a entry,always -F arch=i386 -S oldstat -S oldfstat -S ustat -S
oldlstat -S stat -S lstat -S fstat -S stat64 -S lstat64 -S fstat64
auditctl -a entry,always -F arch=x86_64 -S stat -S fstat -S lstat -S
ustat [1]
It would be really helpful if this kind of knowlege was encapsulated
somewhere. If you were going to put it into auditctl, I suspect you'd
want a separate switch for it so you could still be specific if you
needed it. Is anybody looking at anything like this?
Matt
[1] If anybody points out an error in here, they're just making my point
for me :P
--
Matthew Booth, RHCA, RHCSS
Red Hat, Global Professional Services
M: +44 (0)7977 267231
GPG ID: D33C3490
GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490
17 years
Performance of libauparse
by Matthew Booth
I have been investigating using libauparse in my austream replacement
audit daemon to do some inline data enhancement[1]. austream is
essentially a very thin wrapper which pulls audit records out of the
kernel, wraps them in a UDP syslog packet and sends them to the network.
It is very simple and very fast.
To measure the overhead of libauparse on austream I initialised auparse
as AUSOURCE_FEED, fed each received record into it, and spat them out
unmodified on receiving the AUPARSE_CB_EVENT_READY event. This added
more than an order of magnitude to the time austream spends in
userspace. A brief look at this overhead shows that about 40% is spent
in malloc()/free(), and 25% is spent in strlen, strdup, memcpy, memmove
and friends. I suspect that very substantial gains could be made in the
performance of libauparse by reworking the way it uses memory, and
passing the length of strings around with the strings. Unfortunately, I
suspect this would amount to a substantial rewrite.
Is this something anybody else is interested in? I guess performance
isn't so important if you're just scanning log files in non-real time.
Matt
[1] What I'd really like is a well-defined binary format from the kernel.
--
Matthew Booth, RHCA, RHCSS
Red Hat, Global Professional Services
M: +44 (0)7977 267231
GPG ID: D33C3490
GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490
17 years
Tracking account lockouts and permission denied
by Starr-Renee Corbin
Hello, I am using RHEL 4 and need /var/log/audit/audit.log to show
when an account is locked out and when a user is denied permission to
security relevant files such as /etc/shadow.
This is in conjunction with our NISPOM requirements.
Any help is greatly appreciated!
Corbin
17 years
