Re: What does each audit record field mean?

[Steve Grubb <sgrubb@redhat.com>]

On Tuesday 29 January 2008 02:16:44 Marius.bao wrote:
>   1. My audit rule is auditctl -a exit,always -S open -F success=0,
> why in the audit record, the success field is no. And if I use the
> opposite rule auditctl -a exit,always -S open -F success!=0, the
> records' "success" field is yes?

in the auditctl man page is this: When writing a rule, use a 1 for true/yes 
and a 0 for false/no. It looks like its working the way its documented to 
work.


>   2. In some audit records, the "success" is yes, but with a non-zero
> exit code. When does this situation occur(A syscall successes with a
> non-zero exit code)?

Many times. You would have to look on a per syscall basis. Each one is 
different. For example, open could return a 1 for the descriptor number or 
a -1 to indicate an error. In both cases, it is non-zero. If open returned a 
0, that is also success since that would be stdin. In general, if the exit 
code is < 0, there is an error and >= 0 is success.


>   3.Have anyone ever tested the system performance impact when the
> kernel audit functionality is turned on?

Yes we've done much testing over the years.


>   I've tested with the following audit rules
>   auditctl -a exit,always -S read -F success=0
>   auditctl -a exit,always -S readv -F success=0
>   auditctl -a exit,always -S write -F success=0
>   auditctl -a exit,always -S writev -F success=0
>   auditctl -a exit,always -S fork -F success=0
>   auditctl -a exit,always -S clone -F success=0
>   auditctl -a exit,always -S truncate -F success=0
>   auditctl -a exit,always -S ftruncate -F success=0
>   auditctl -a exit,always -S link -F success=0
>   auditctl -a exit,always -S unlink -F success=0
>   auditctl -a exit,always -S symlink -F success=0
>   auditctl -a exit,always -S chown   -F success=0
>   auditctl -a exit,always -S chmod  -F success=0
>   auditctl -a exit,always -S fchown -F success=0
>   auditctl -a exit,always -S fchmod -F success=0
>   auditctl -a exit,always -S kill -F success=0
>   auditctl -a exit,always -S mmap -F success=0
>   auditctl -a exit,always -S signal -F success=0

This is going to suck performance-wise. If you wanted to audit the above, I'd 
re-write the rules as:

auditctl -a exit,always -S read -S readv -S write -S writev -S fork -S 
clone -S truncate -S ftruncate -S link -S unlink -S symlink -S chown -S 
chmod  -S fchown -S fchmod -S kill -S mmap -S signal -F success=0

This means that the kernel will evaluate just one rule that does the same 
thing. I can do it this way because all syscalls are on the same filter and 
with the same action and they check the success field the same way.

When doing syscall auditing always try to combine rules where you can. Each 
syscall rule gets evaluated for every syscall every program makes. It adds 
up. Try to use file based auditing whenever you can since its not as big of a 
performance hit.


>     It turned out that with some of the audit rule set, the kscope
> source compile process takes double time. I wonder why it has so heavy
> impact on the system's performance.

See above.


>     I also read some papers(<<Automatic high-performance
> reconstruction and recovery>>) on other audit systems. The system's
> impact is relatively low,about 6%~8% with all syscall information
> audited.

If you can think of a faster way to do what we are doing, please submit kernel 
patches. Any performance improvements would be appreciated.

-Steve