Re: Use case not covered by the audit library?

[Steve Grubb <sgrubb@redhat.com>]

On Thursday, December 17, 2015 01:10:03 AM Richard Guy Briggs wrote:
> > No, this is an HTTP server that handles standard HTTP requests like GET,
> > POST, PUT, and DELETE.  The URI specifies what resource is being acted
> > upon.  These requests could come from something as simple as curl, or a
> > full blown management application, or a web GUI (which is interactive in
> > the browser).  For example, you could issue a POST request to URI
> > /openswitch/v1/users to create a new user.  The body of the request would
> > contain JSON or XML data indicating the user and password.  There are
> > pre-determined actions/resources that can be changed.   In standard REST
> > APIs, all of the URIs, their parameters and the scheme of the body are
> > documented and only these requests can be issued.>
> > 
> >
> > It's based on client/server and the client may or may not be interactive
> > (e.g. a web browser).   In these types of servers, we'd almost
> > exclusively be using the audit_log_user_message() API with an event type
> > of AUDIT_USYS_CONFIG.   We're only logging configuration changes to the
> > switch.   I think I don't understand how the "message" parameter is used
> > in this call.  The man page implies a simple text message, but looking at
> > the audit.log file it appears to consist of a set of key-value
> > pairs.   Is my understanding correct?>
> > 
> >
> > 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.

-Steve