Re: should I loose audit data if I only care about the record's fields?

[John Dennis <jdennis@redhat.com>]

Klaus Heinrich Kiwi wrote:
> Hi,
> 
>  when I started building my dispatcher plug-in, I assumed that I'd only
> need the fields values in each record to have all the data I needed. My
> plug-in for remote logging aimed at consolidating the audit data in
> another server, so I probably need all the audit data I can get from the
> Audit subsystem, possibly in a format that is compatible with the target
> system (thus using the record fields for mapping)
> 
> Giving another look the some audit records, I saw that this approach was
> probably not sufficient to describe the audited operation as a whole.
> 
> Example record:
> type=USER_CHAUTHTOK msg=audit(1194995431.057:58485): user pid=30759
> uid=0 auid=0 subj=root:system_r:unconfined_t:s0-s0:c0.c1023
> msg='op=adding user to shadow group acct=klausk
> exe="/usr/sbin/usermod" (hostname=?, addr=?, terminal=pts/1
> res=success)'
> 
> using walk_test() from the test routine (python):
> ---
> event 1 has 1 records
>     record 1 of type 1108(USER_CHAUTHTOK) has 12 fields
>     line=1 file=None
>     event time: 1194995431.57:58485, host=None
>         type=USER_CHAUTHTOK (USER_CHAUTHTOK)
>         pid=30759 (30759)
>         uid=0 (root)
>         auid=0 (root)
>         subj=root:system_r:unconfined_t:s0-s0:c0.c1023
> (root:system_r:unconfined_t:s0-s0:c0.c1023)
>         op=adding (adding)
>         acct=klausk (klausk)
>         exe="/usr/sbin/usermod" (/usr/sbin/usermod)
>         hostname=? (?)
>         addr=? (?)
>         terminal=pts/1 (pts/1)
>         res=success (success)
> ---
> 'op=adding' - adding what? no information about what's going on here.
> _side note_: just noticed that the original record is telling 'adding
> user to shadow group' when in fact I was adding the user to the 'nobody'
> group, plus others, with 'usermod -G' - I'll check that again later.
> 
> Another example is the LOGIN record:
> original record:
> type=LOGIN msg=audit(1193547601.367:36782): login pid=11698 uid=0 old
> auid=4294967295 new auid=0
> 
> ---walk_test()----
> event 1 has 1 records
>     record 1 of type 1006(LOGIN) has 5 fields
>     line=1 file=None
>     event time: 1193547601.367:36782, host=None
>         type=LOGIN (LOGIN)
>         pid=11698 (11698)
>         uid=0 (root)
>         auid=4294967295 (unset)
>         auid=0 (root)
> ---
> two auid fields? which is old and which is new? ok maybe not the
> brightest example but IMO still valid.
> 
> There are probably more examples besides those two. 
> 
> Maybe auparse is aimed to just help us when we need to extract data, but
> it is well-settled that someone will need the whole record to actually
> know what's going on - please tell me if that is the case.

I'm not sure follow what you're asking but let me through a few thoughts 
out.

auparse only purpose is to parse and extract audit data, it doesn't 
interpret the data (other than simple things like mapping numeric values 
to strings). The job of interpreting the audit event is up to the caller 
of auparse. During interpretation only you can know what data you need 
to look at. There may or may not be a relationship between individual 
events, you're going to have to perform some analysis across events to 
determine if that is the case.

When you say "only need the field values" are you saying you're throwing 
away the field names and if so what about multiple fields with the same 
name?

Also, be aware records in an event cannot be merged because the same 
fields may appear in more than one record, if you do that you'll have 
collisions and lose all but the most recent field value you read out of 
the event.

In the above example, if the op field was really a multiword string but 
its value only appeared as the first word in the string, then that looks 
like a bug. I'm not personally familiar with that field in that record.



> Thoughts?
> 
>  Klaus
>  
> 
> --
> Linux-audit mailing list
> Linux-audit@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-audit


-- 
John Dennis <jdennis@redhat.com>