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

[Linda Knippers]

Steve Grubb wrote:
> On Wednesday, January 11, 2012 04:10:16 PM Eric Paris wrote:
>> So I realized today that we have overlapping information in records and
>> I don't like it.
> 
> I have a real strong feeling that you did it. :-)  I'm not searching the 
> archives for proof...but I remember it went something like this...we needed a 
> MAC event showing it changed. We needed some basic info. Then later we needed 
> some more info and then someone just changed it to dump the syscall record. In 
> many cases, this is bloat.
> 
> What is required is much less fields and I would like to keep the overall event 
> size as small as possible. Do I need a MAC_STATUS event?  Yes. Do I need to know 
> the syscall? no.
> 
> 
>> 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?
> 
> What is required is this:
> Date and time of the event, 
> type of event, 
> subject identity (if applicable), 
> the outcome (success or failure) of the event
> and additional data depending on the event, like what configuration item changed 
> (with old and new values), what was accessed, etc.
> 
> We have additional requirements of being able to trace each event back to an 
> actual login hence the session data. Then you also have to record enough 
> information about the subject that its useful. This includes at a minimum auid, 
> uid, pid, and selinux context.
> 
> 
>> Why not other info like the SELinux context? 
> 
> I think when we asked for that, you added a line of code to grab the whole 
> syscall since that was the simplest thing to do. :-)
> 
> 
>> 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
> 
> Probably too much info and too late. I have a feeling that a change like this 
> now would cause more problems than its worth.
> 
> I want to aim the audit system such that it can meet the new basic robustness 
> protection profile. Meeting it would also allow meeting any other PP that I know 
> of. It will require reviewing all audit records to make sure they conform to the 
> new requirements.
> 
> http://www.niap-ccevs.org/pp/PP_GPOSPP_V1.0/
> 
> I'd really like to avoid any massive changes in record format until that work 
> begins in earnest later this year. I want to create some regression testing 
> tools in the mean time so that as we move forward, we can stay backwards 
> compatible. 

Feel free to submit patches for any missing tests to audit-test-developer at lists.sourceforge.net.

> Imagine an aggregating server with several different Linux platforms 
> being aggregated and still being able to use the current tools. It has to be 
> done.
> 
> Please, let's not go down this rat hole just yet. I'd rather catch up on the 
> known bugs in the audit system like 
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=742562
> 
> then around summer/late spring start working towards GPOSPP's requirements and 
> possibly reformat some events as part of that work.
> 
> -Steve
> 
> --
> Linux-audit mailing list
> Linux-audit at redhat.com
> https://www.redhat.com/mailman/listinfo/linux-audit