Auditing file access by application

[John Petrini]

Okay thank you both. I'll look into dbus as a possible solution.

By the way this is a CentOS 6.9 box running kernel 2.6.32-696.1.1.el6.i686

___

John Petrini

NOC Systems Administrator   //   *CoreDial, LLC*   //   coredial.com
//   [image:
Twitter] <https://twitter.com/coredial>   [image: LinkedIn]
<http://www.linkedin.com/company/99631>   [image: Google Plus]
<https://plus.google.com/104062177220750809525/posts>   [image: Blog]
<http://success.coredial.com/blog>
Hillcrest I, 751 Arbor Way, Suite 150, Blue Bell PA, 19422
*P: *215.297.4400 x232   //   *F: *215.297.4401   //   *E: *
jpetrini at coredial.com


Interested in sponsoring PartnerConnex 2017? Learn more.
<http://success.coredial.com/partnerconnex-2017-sponsorship>

The information transmitted is intended only for the person or entity to
which it is addressed and may contain confidential and/or privileged
material. Any review, retransmission,  dissemination or other use of, or
taking of any action in reliance upon, this information by persons or
entities other than the intended recipient is prohibited. If you received
this in error, please contact the sender and delete the material from any
computer.

On Mon, Jun 12, 2017 at 11:52 AM, Steve Grubb <sgrubb at redhat.com> wrote:

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/linux-audit/attachments/20170612/778f1027/attachment.htm>