Re: Use case not covered by the audit library?

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

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