Use case not covered by the audit library?

Burn Alting burn.alting at gmail.com
Wed Dec 16 19:55:54 UTC 2015


On 17 Dec 2015 1:24 am, "Steve Grubb" <sgrubb at redhat.com> wrote:
>
> 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
>
Scott,

If you have to use auditd as your auditing framework, then can you
a. Test your application running on a system with a comprehensive autiting
posture already deployed. That is take a CAPP configuration and add execve
system call monitoring. I have found applications that extensively use
auditd for application audit, slow down in such an environment.
b. If you use the auditd api then please use well formed key value pair
content in your events. Follow the auditd documentation in this reguard. If
not well formed, tools using auparse () and friends may discard data during
the parsing.

Regard
Burn
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/linux-audit/attachments/20151217/8c9c216e/attachment.htm>


More information about the Linux-audit mailing list