Proposed additions to ausearch

[Steve Grubb]

Hello,

On Sunday, May 05, 2013 06:21:57 PM Burn Alting wrote:
> I have completed all the items listed below against ausearch. That is
> 
>         - it can now checkpoint itself, in that, successive invocations
>         will only display new events

Go ahead and send this one. It shouldn't disturb other work.

>         - a new option will print out more parser friendly output for
>         interpreted mode

I am in the midst of coalescing the interpreters into one. I know this sounds 
crazy, but ausearch and auparse both had independent copies of nearly the same 
material. The problem was they both keep data formatted completely different 
and that made combining them a challenge. I think auparse has a faster lookup 
algorithm but it allocates memory for the translation. So, I hope they cancel 
each other out.

My point in mentioning this is that I am probably in the middle of changing 
code you hooked into. The work is checked in but still in progress. The first 
step was to create a common API for 3 functions used in translating fields. 
(This is checked in.) The next step is to link ausearch against auparse with 
the ausearch functions commented out. The final step is to remove all the 
unneeded code from ausearch. (I should be doing this today.)


>         - a new option will also print out some values both in it's
>         original as well as interpreted form

This is something I'm still pondering what the best approach is. It could be 
possible to generate an audit uid/gid mapping when the audit daemon starts and 
add that as a record. Ausearch can use this record as needed. Then any user 
add/delete events could be added to a table for display. The problem comes 
when you have really large installs in which case it might be best to have a 
static uid mapping for all users and they have to always use the same uid no 
matter which system they log into. Of course this gets tricky for system 
services which can have a different uid from machine to machine.

Another way of doing this would be to add a translation record to each event. 
This increases the storage size, though.


> Whilst doing this, I fixed some very minor bugs or annoyances.
> 
>         - when ausearch processes events, incomplete events are
>         considered as complete (and hence printed) when ausearch
>         encounters an EOF on input. Now, ausearch will carry over
>         incomplete events, providing the opportunity to complete them,
>         unless it's the last file ausearch is processing

Go ahead and send this.


>         - ausearch -i now identifies ANY quoted values on input and
>         considers these values of type T_ESCAPED and hence will be
>         processed via the print_escaped() routine. It was noticed keys
>         such as ocomm, dev and op could have quoted values as per
>                 ... opid=717 oauid=42 ouid=0 oses=1
>                 obj=system_u:system_r:xdm_t:s0-s0:c0.c1023
>                 ocomm="gdm-session-wor"

I'll fix this...thought I had them all.


>                 ... avc:  denied  { read } for  pid=21340
>                 comm="unix_chkpwd" name="libaudit.so.1.0.0" dev="dm-1"
>                 ino=394483
>                 scontext=system_u:system_r:chkpwd_t:s0-s0:c0.c1023
>                 tcontext=system_u:object_r:default_t:s0 tclass=file

Yes, I saw this one yesterday. I think the root cause of this is the AVC text 
is malformed. dev is already used and its a device number, not a name. This 
field's name should change since its recording the wrong value for that field's 
name.

>                 ... auid=4294967295 ses=4294967295
>                 subj=system_u:system_r:init_t:s0 op="add rule"
>                 key="time-change" list=4 res=1

This is malformed because the kernel is doing it wrong. Its code must be fixed. 
Additionally, I am certain there are other cases of this.


>         The change identifies ANY value with double quotes around the
>         value and offers their interpretation via the print_escaped()
>         routine. The alternative is to add the above three keys to the
>         typetab[] array.

Sometimes this catches problems on the event logging side.
 
>         - when processing flag values in interpretive mode, a trailing
>         space was always printed whether the flags key value pair was
>         the last pair on the event record or not.

Not sure about this one...but it should be checked after the ausearch/parse 
redundancy is fixed.


> Should I submit this as one patch or multiple? I have a single patch
> file (including mods to ausearch.8) but if required, I may be able to
> present each new feature as it's own patch and/or the bugs as a group.
> 
> The patch(es) would be against audit-2.3.

Its best to submit these one by one. It probably would have been best to send 
these as you completed each item so they could be reviewed/discussed/merged at 
leisure.

Thanks,
-Steve