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.

Hello, 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

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

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

-----Original Message----- From: Steve Grubb [mailto:sgrubb@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@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.

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

-----Original Message----- From: Steve Grubb [mailto:sgrubb@redhat.com] Sent: Wednesday, January 06, 2016 12:06 PM > > 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. The USYS_CONFIG event is like this: type=USYS_CONFIG msg=audit(1389095562.552:540): pid=2249 uid=0 auid=4325 ses=1 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='op=change-system- time exe="/usr/sbin/hwclock" hostname=? addr=? terminal=pts/0 res=success' The kernel supplies all the pieces up to the msg= portion. After that is what you build. The only real field the event writer does is the op= field, The rest are supplied by libaudit. Ausearch does not parse the op= field. What I would suggest in a case like this is to create a small utility that generates the exact report that you want. The auparse library makes that super easy. I can dig up the skeleton code for something like this if you want.