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