Auditing file access by application

Auditing file access by application

[John Petrini]

[-- Attachment #1.1: Type: text/plain, Size: 1030 bytes --]

Hello,

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.

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?

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

Thank You,

___

John Petrini

[-- Attachment #1.2: Type: text/html, Size: 1847 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: Auditing file access by application

[Richard Guy Briggs]

On 2017-06-12 10:20, John Petrini wrote:
> Hello,

Hi John,

> 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.
> 
> 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?
> 
> I was hoping to us something like -F exe!="/path/to/application" but it
> looks like this is not supported.

How about trying:

-a never,exit -S all -F exe="/path/to/application" -F dir=/path/to/voicemail -F perm=rwxa -F auid!=voicemail_user -F key=voicemail_watch
-a always,exit -S all -F dir=/path/to/voicemail -F perm=rwxa -F auid!=voicemail_user -F key=voicemail_watch

Meanwhile, I've filed an issue to add negation to "-F exe=".
	https://github.com/linux-audit/audit-kernel/issues/53

I hope this helps.

> John Petrini

- RGB

--
Richard Guy Briggs <rgb@redhat.com>
Sr. S/W Engineer, Kernel Security, Base Operating Systems
Remote, Ottawa, Red Hat Canada
IRC: rgb, SunRaycer
Voice: +1.647.777.2635, Internal: (81) 32635

Re: Auditing file access by application

[John Petrini]

[-- Attachment #1.1: Type: text/plain, Size: 205 bytes --]

Hi Richard.

It looks like the -F exe= option is not supported at all regardless of
negation.

Starting auditd:                                           [  OK  ]
-F unknown field: exe


___

John Petrini

[-- Attachment #1.2: Type: text/html, Size: 955 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: Auditing file access by application

[Richard Guy Briggs]

On 2017-06-12 11:31, John Petrini wrote:
> Hi Richard.
> 
> It looks like the -F exe= option is not supported at all regardless of
> negation.
> 
> Starting auditd:                                           [  OK  ]
> -F unknown field: exe

Support is upstream in Linux kernel v4.3 and userspace audit-2.5.0.
It is in RHEL7 kernel-3.10.0-351.el7

> John Petrini

- RGB

--
Richard Guy Briggs <rgb@redhat.com>
Sr. S/W Engineer, Kernel Security, Base Operating Systems
Remote, Ottawa, Red Hat Canada
IRC: rgb, SunRaycer
Voice: +1.647.777.2635, Internal: (81) 32635

Re: 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

Re: Auditing file access by application

[John Petrini]

[-- Attachment #1.1: Type: text/plain, Size: 3756 bytes --]

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

[-- Attachment #1.2: Type: text/html, Size: 6849 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]