Re: New List Member: Intro & comments
On Monday 31 July 2006 13:14, Clif Flynt wrote:
As I read things, AppArmor doesn't support the file audit
requirements, but Auditd can meet the DSS requirements.
Its not the responsibility of the access control mechanism to support audit.
Audit has its own kernel patches for this. I don't know if Suse picked up
those patches since yhey are in the upcoming 2.6.18 kernel.
Auditd 1.2.5 doesn't quite do what I need, but I'm getting
close.
What doesn't it do?
2) Maintaining records
The traditional log-rotate with N logs makes it difficult to keep X
days of logs. When the system is busy, I can rotate the logs every 10
minutes.
Long term, I want to natively support compressed logs by linking to gzip
library and using it.
I've put together a small cron job that looks for audit.log.1,
filters out some data I know I won't want, and zips it into a file with
a name based on the timestamp.
The 2.6.17 kernel lets you delete certain message types in the kermel. You
would do something like:
-a always,exclude -F msgtype=login
This will filter all those message types in the kernel so they never make it
to the logs.
My current report generator builds an SQLite database on the fly
from
the flat ASCII logs.
Seems like this would be ideal to marry to the realtime audit event interface.
You would set log_format = nolog, dispatcher = /sbin/your-dispatcher, and
disp_qos = lossless to keep the audit system from writing to disk, send
events to a program, and use blocking comminucation to do it.
I'm using SQLite instead of mySQL or Postgres because it
it's fast,
mature and robust and doesn't require any database server (or dbadmin)
to run it.
I've been looking at using it too. I read some issues that made me wonder if
it was really suitable:
http://www.sqlite.org/whentouse.html
At the bottom it mentions that if something has the database open for read,
then writing is blocked. And the issue about the journal using 256 bytes for
event MB of data made me wonder also.
I agree that this fits a database model and have been working to normalize the
data so we can actually do this. I think all that's left to do is work on the
avc messages since they seem to be overloaded.
I put together a small audisp test application to read from stdin
and
save data in a timestamped file. When I run this, I get nothing but
empty reads, and finally an EOF from auditd. I'm expecting to see
plain ASCII input.
Yes, you should.
Is this not what is sent to the audisp target?
No, real data is sent. The descriptor is likely to be non-blocking so that the
audit deamon doesn't hang up when the buffers are full. So, you need to
select on the descriptor.
I just tried the sample.c application,
skeleton.c? That should work fine.
When I restart audispd, I see no output in /var/log/messages, and
a.out does
not show in the process stack. If I just run /tmp/a.out and type something,
output appears in /var/log/messages.
Hmm strange. Works on FC6 machine.
If any of this is of interest or use, let me know, and I'll
make it
available to the community.
The GUI based search tool might be nice for people to use. I plan to write one
in the future, but its lower on the priority list right now. But I think
people would like to try out your tool.
-Steve