Use case not covered by the audit library?

[Gulland, Scott A]

> -----Original Message-----
> From: Steve Grubb [mailto:sgrubb at redhat.com]
> Sent: Wednesday, January 06, 2016 8:29 AM
> 
> On Tuesday, January 05, 2016 09:59:25 PM Gulland, Scott A wrote:
> > > -----Original Message-----
> > > From: Steve Grubb [mailto:sgrubb at redhat.com]
> > > Sent: Thursday, December 17, 2015 6:51 PM
> > >
> > > 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.

Unfortunately, that is not true for HTTP servers which run as root but
authenticates the true user issuing the REST request.   The authentication is
done through PAM.  The HTTP server then carries out the action on behalf 
of that user.   The kernel thinks it's a root user, but the HTTP server knows
otherwise.   It sounds like there is no way for a trusted user app to inject
the correct uid into the audit event.   Would you recommend I use the
"user" field instead of "euid" to indicate who is issuing the request?

> > 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.

I am using the AUDIT_USYS_CONFIG event type as I would like to use
"aureport -c" to get a summary of the configuration changes to the switch.
As an alternative, I could use the AUDIT_TRUSTED_APP event type.

Scott G.
> 
> > 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.