RE: Use case not covered by the audit library?
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.
Thanks,
Scott