audit message types

[Steve Grubb]

Hello,

I wanted to start a discussion about an old topic that we last discussed back 
in December. The problem basically centers around the audit message type 
being too coarse to be of any real use. Right now, we have 3 message types 
that the kernel sends to the audit daemon: AUDIT_KERNEL, AUDIT_USER, and 
AUDIT_LOGIN.

AUDIT_LOGIN is fine. Its a very specific message. AUDIT_USER can be used for 
anything from userspace. Anything means pam going through its various phases 
- authentication, account management, session start, credentials set, session 
closed, credentials destroyed. It also means any error message that may come 
out of pam. Various trusted applications use it to note any kind of change to 
user account attributes and any error therein.

We are trying to create an audit system that meets CAPP requirements (Section 
FAU_SAR.3). We need to allow the administrator to create searches that, for 
example, let them find any failed attempt to change a user's password. What 
this means is that we have to search for any record that is of type 
AUDIT_USER, then examine each one of those looking for the one that comes 
from passwd. (Or maybe they were logging in and login made them change their 
passwd since it expired. Two potential message sources for the same action.) 
That's way too many messages to parse to find one specific kind of event.

I also feel that the kernel needs to break its packets down a little better 
for searching. For example, both of these are KERNEL types:

type=KERNEL msg=audit(1113856292.392:10258978): item=0 name="/usr/bin/kompare" 
inode=589078 dev=03:02 mode=0100755 uid=0 gid=0 rdev=00:00

type=KERNEL msg=audit(1113856292.392:10258978): syscall=11 arch=40000003 
success=yes exit=0 a0=86629c0 a1=865f280 a2=85a6870 a3=805264c items=2 
pid=4078 loginuid=525 uid=525 gid=525 euid=525 suid=525 fsuid=525 
egid=525 sgid=525 fsgid=525 comm="kompare" exe=/usr/bin/kompare

But the first is a helper (or supplementary info) for the second. It would be 
so much easier if the first one was a different message type. For example, 
suppose we have to do a search for a specific uid. which one of the above 
should we "hit" on? The seocnd one obviously, but it would be better if it 
was a different type so the ausearch program has a spot to key on for data 
about the event.

Then to top it off, we have SE Linux avc messages in the mix.

I think it would be a tremendous help to add some new message types that can 
be filtered on. For example, if we had more kernel message types so SE Linux 
avc denials were a differnt message type from syscall auditing, I could 
easily add a filter to auditd so that a user can specify what kind of message 
types they want logged. This will let them save disk space and improve 
performance.

For example, someone writing SE Linux policy may want AUDIT_SELINUX_AVC_DENIAL 
messages only. Everything else could be thrown away as far as they are 
concerned. Or maybe people want to log only AUDIT_LOGIN messages. Some people 
may want to log only failures to log in. Without finer grained message types, 
this is not even a possibility.

In addition, if a user has 10 gigabytes of audit messages and they are all 
AUDIT_KERNEL and they want to do a search on failed login attempts, 
performance is going to suck. The reason, is because we will have to parse 
many of the wrong kind of messages just to find the ones we are looking for.

To solve the problem, I would like to propose that AUDIT_KERNEL be used only 
for things like adding & deleting rules, changing backlog, failure flag, 
enabled/disabled, and message rate limit. We should introduce new message 
types that partition the messages into: event, supplementary  information 
(for example - look at the log snippet above, the first chunk is this type), 
SE Linux, authentication, account attribute change, account management, 
credentials, session start, session close. 

Of these, supplementary information should be subdivided into various types, 
AUDIT_FILE_INFO for example. The SE Linux messages should be subdivided into 
various message types, too. The rest would have a success and failure 
subtype.

The benefits to doing this is: ausearch can better search for the right 
information, users can filter what goes to disk, audit records are easier for 
people to read, test cases are easier to construct.

Thoughts?

-Steve Grubb