Auditing file access by application

[Steve Grubb]

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