Relying on syscall record for information and useless key/value duplication

Eric Paris eparis at redhat.com
Wed Jan 11 21:10:16 UTC 2012


So I realized today that we have overlapping information in records and
I don't like it.  A great example would be the MAC_STATUS record and how
you can get duplicate info.  Looking at that following output.

type=MAC_STATUS msg=audit(1326314451.473:1018): enforcing=0 old_enforcing=1 auid=4166 ses=2
type=SYSCALL msg=audit(1326314451.473:1018): arch=c000003e syscall=1 success=yes exit=1 a0=3 a1=7fffc73e1200 a2=1 a3=0 items=0 ppid=3110 pid=21435 auid=4166 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts3 ses=2 comm="setenforce" exe="/usr/sbin/setenforce" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null)

What you see is that the MAC_STATUS record tells us more than about the
mac status.  It also includes the auid and ses.  Why only that info?
Why not other info like the SELinux context?  What really bothers me is
that We already get that info (and a lot more info) in the SYSCALL
record.  I believe this is bogus.  What I'd like to do is to create a
new record called the 'TASK_INFO' record that will contain:

ppid pid auid uid gid euid suid fsuid egid sgid fsgid tty ses comm exe
subj

And have this record be 'automagically' emitted any time any record is
emitted.  Thus we don't have information duplication and even if you
have rules to exclude the SYSCALL record you still get all the info you
ever needed for the MAC_STATUS record you wanted.

Does this make sense?  Is there a reason not to do this?  It makes the
code smaller, faster, easier to maintainer, and MUCH easier to prove
correct and complete.  It logically separates the info that is from the
task doing the action from the records which are supposed to report on
individual actions.

Shouldn't MAC_STATUS be about the mac status?  Shouldn't config change
records be about the config that changed?  Shouldn't the xfrm records be
about XFRM?  Obviously attributing these actions to a given task is
important, but it isn't being put where it belongs.




More information about the Linux-audit mailing list