Hello,

On Monday, June 12, 2017 10:20:15 AM EDT John Petrini wrote:
> We have a need to monitor voicemail directories for any sort of access.
> Basically there is only one application that should be accessing the files.
> If anything else accesses the files we need to log that.
>
> We setup the following to accomplish this but it's doesn't quite do what we
> want.
>
> -a always,exit -S all -F dir=/path/to/voicemail -F perm=rwxa -F
> auid!=voicemail_user -F key=voicemail_watch
>
> voicemail_user is the user that initially starts the process. The problem
> arises when someone logged in under a different account restarts the
> process. From that point forward every time the application accesses that
> directory it results in a log message.

This is a common problem with old SysVinit style systems. This works correctly
on Systemd based init systems. I thought at one point that Upstart had fixed
this, but I cannot find any reference in the Changelog that indicates it was
fixed.

The best solution is to write another daemon to start your application. Signal
it to restart the application using some IPC mechanism. The basic issue is
that the credentials are inherited from the login to all processes in the
login. So, you need to restart the application from a clean environment where
login credentials haven't leaked.

This leaking of credentials between all processes in a login session is by
design so that attackers cannot undo the breadcrumb trail left by the audit
system.

> We need other users to be able to be able to log in and restart the process
> so our method here really doesn't work. Is there a way to log only if a
> different application access the directory rather than basing the audit on
> user?

This really is telling you that the application is getting the whole login
environment of the user restarting the application. You might try exploring
dbus activation.

https://dbus.freedesktop.org/doc/system-activation.txt

And then limit who can run that application by some group id.

chmod 0750 /path/dbus-activation-launcher
chgrp wheel  /path/dbus-activation-launcher

> I was hoping to us something like -F exe!="/path/to/application" but it
> looks like this is not supported.

You haven't mentioned what kernel or init system you have, but it sounds like
its not recent. Dbus activation is probably the cleanest way to fix the issue.

-Steve