On 15/12/17, Gulland, Scott A wrote:
> Hi Steve,
>
> > On Tuesday, December 15, 2015 05:13:14 AM Gulland, Scott A wrote:
> > > I have a fairly common use case that I'm not sure is covered by the audit
> > > library and I need some advice on how best to handle it. I have a daemon
> > > running as root that services REST API calls (or a web UI from a browser).
> > > An external application first establishes a session by authenticating a
> > > user which returns a token/session ID to the caller. All future REST API
> > > calls, supplies the token/session ID which allows them authenticated
> > > access
> > > to the requested resource. The token/session ID indicates what user the
> > > request is associated with. Obviously, there can be many users
> > > simultaneously issuing requests.
> > >
> > > What I need to do is specify the user on each audit log call. For
> > > example,
> > > I need to have a way to specify which user is issuing the request when I
> > > call audit_log_user_message(). Is this possible? This is a very common
> > > use case and really needs to be handled.
> >
> > Would these users be able to interact with the system in any way they
> > please?
> > If its not an interactive session, then I don't think its a _system_ event.
> > There are perfectly fine application logging frameworks to choose from. The
> > main issue is making sure that users cannot influence the records being
> > written about what they are doing.
> >
> > But if you feel that you really would like to have this in the audit trail,
> > then
> > you can use the AUDIT_TRUSTED_APP event type and format the event any
> > way that you wish. The audit tools sort of ignore those events because
> > there's no telling what's in them.
> >
> > -Steve
>
> 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,
>
> Scott
- RGB
--
Richard Guy Briggs <[email protected]>
Senior Software Engineer, Kernel Security, AMER ENG Base Operating Systems, Red
Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635, Alt: +1.613.693.0684x3545
--
Linux-audit mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/linux-audit
