New List Member: Intro & comments
Steve Grubb
sgrubb at redhat.com
Mon Jul 31 17:54:30 UTC 2006
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
More information about the Linux-audit
mailing list