Re: Use case not covered by the audit library?

[Steve Grubb <sgrubb@redhat.com>]

On Tuesday, January 05, 2016 09:59:25 PM Gulland, Scott A wrote:
> > -----Original Message-----
> > From: Steve Grubb [mailto:sgrubb@redhat.com]
> > Sent: Thursday, December 17, 2015 6:51 PM
> > 
> > > > My problem is I don't know what the proper set of "keys" are and the
> > > > values they should contain.  If my assumptions are correct, is there
> > > > any documentation on on the key-value pairs and how to format the
> > > > contents of the message parameter?  Based on what I've seen in the
> > > > audit log file, I would add "acct=<user>" to the contents of the
> > > > message to reflect the particular authenticated user who issued the
> > > > REST
> > 
> > API call.
> > 
> > > Well, Steve has published these as a starting point.  I'm sure he'll
> > > chime in when he sees your message.
> > > 
> > >         http://people.redhat.com/sgrubb/audit/audit-events.txt
> > >         http://people.redhat.com/sgrubb/audit/audit-parse.txt
> > 
> > Thanks for pointing these out, Richard.
> > 
> > The basic guidance for AUDIT_USYS_CONFIG is to record old and new values.
> > Typically old values are prefixed with 'old-' and new values are the name
> > of the field with no prefix.
> > 
> > Any field that the user could influence the value has to be handled in
> > such a way as to not allow them to trick the parser if they are
> > malicious. For the most part, we hex encode those fields and then write
> > some code to label the fields as encoded so that interpretation can be
> > done later.
> > 
> > Since your field names may not be official names in the audit system, you
> > may have to filter illegal characters the user sent during event
> > construction and fill in spaces with an underscore or dash.
> 
> Thanks for the feedback and information.  It has been very helpful.  I've
> done some testing using a "val" and "old-val" field names with data values
> encoded by audit_encode_nv_string(...).  However, when I try to display the
> event with "ausearch --interpret ..." neither field's data is decoded back
> into asci text.

It has to be a field name that auparse expects to be encoded.


> So I plan on using the "op", "data" and "euid" fields.  

euid would be a kernel originating field name. User space could lie about it. 
The kernel is the only thing that knows the truth.


> Only the data field needs to encoded and ausearch does decode this field
> correctly.  My message text would look like:
> 
>     "op=<op text> data=<encoded data> euid=<uid>"
> 
> When I was using ausearch I expected to be able to find events by uid using
> either the "-ua" or "-ue" option that would match the euid field's value,  
but no matching events were found.  Is this expected behavior?

What is the record type? ausearch is optimized to expect certain record types 
to have fields in a specific order.


> The "-I" option did correctly convert the euid into the user name.

Interpreting and searching are different areas of the code base and are 
independent. Interpreting is done after searching. No need to interpret fields 
that will never be output.

-Steve