Re: should I loose audit data if I only care about the record's fields?
(sorry about the html posting)
John Dennis <jdennis(a)redhat.com> wrote on 11/14/2007 09:30:16 AM:
> 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)
> ---
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?
That got out bad. I wanted to know if by having only the event type,
event timestamp+serial, and all the fieldname=value pairs would be
sufficient to describe an audit record completely. Look at the above
example (taken out of auparse testsuite). Can I describe the record
as a whole if I just have the data that 'walk_test()' gives me? I'd
expect so, but there are still some audit data not placed in any
field.
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.
I'm not merging records. In the plug-in, I use the same concept applied
in the Linux Audit subsystem, that is having a unique identifier shared
among all the records of a same 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.
It seems like a field value cannot contain any spaces, so the 'operation'
specified by usermod should be something like
'op=adding-supplemental-group-to-user new_group=sys acct=klausk'.
But then again we have another issue: it's up to the application to choose
the operation name, the field name and what it means - or if there is any
field at all! This many degrees of freedom may mean hell to people who
actually are trying to extract information from these records.
Standard formats, standard fields names with well-known meanings would
certainly help.
Thanks,
Klaus
--
Klaus Heinrich Kiwi/Brazil/IBM <klausk(a)br.ibm.com>
Software Engineer
IBM STG, Linux Technology Center
Phone:(+55-19) 2132-1909 [T/L 839-1909]
Attachments:
- attachment.html (text/html — 4.3 KB)