Re: New List Member: Intro & comments

[Steve Grubb <sgrubb@redhat.com>]

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