Excluding stat syscall logging for specific path

Excluding stat syscall logging for specific path

[Vincas Dargis]

Hi,

When playing/learning with auditd, I wanted to log events when apache fails to access file.

Here's the rules I used in Debian Wheezy (same on Jessie and and current latest Testing):

-a exit,never -F arch=b64 -S stat -F path=/var/www/server-status -k web
-a exit,always -F arch=b64 -S stat -F uid=www-data -F success=0 -k web

/var/www/server-status file is non-existant, it's just alias for accessing mod_status information ( 
http://.../server-status path is accessed by munin regularly) so I wanted to minimise noise by that exit,never rule.

But I can't get it work.

I have more in-depth post in Debian forums [1] if that helps, but in short, should this work in general?

Thanks!

[1] http://forums.debian.net/viewtopic.php?f=5&t=128092

Re: Excluding stat syscall logging for specific path

[Steve Grubb]

On Friday, April 29, 2016 08:56:26 PM Vincas Dargis wrote:
> Hi,
> 
> When playing/learning with auditd, I wanted to log events when apache fails
> to access file.
> 
> Here's the rules I used in Debian Wheezy (same on Jessie and and current
> latest Testing):
> 
> -a exit,never -F arch=b64 -S stat -F path=/var/www/server-status -k web
> -a exit,always -F arch=b64 -S stat -F uid=www-data -F success=0 -k web
> 
> /var/www/server-status file is non-existant,

Is it a symlink? If it really doesn't exist, then there is no inode to match 
against.


> it's just alias for accessing
> mod_status information ( http://.../server-status path is accessed by munin
> regularly) so I wanted to minimise noise by that exit,never rule.
> 
> But I can't get it work.

What kernel are you using?

-Steve

> I have more in-depth post in Debian forums [1] if that helps, but in short,
> should this work in general?
> 
> Thanks!
> 
> [1] http://forums.debian.net/viewtopic.php?f=5&t=128092
> 
> --
> Linux-audit mailing list
> Linux-audit@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-audit

Re: Excluding stat syscall logging for specific path

[Vincas Dargis]

2016.04.29 21:00, Steve Grubb rašė:
> On Friday, April 29, 2016 08:56:26 PM Vincas Dargis wrote:
>> Hi,
>>
>> When playing/learning with auditd, I wanted to log events when apache fails
>> to access file.
>>
>> Here's the rules I used in Debian Wheezy (same on Jessie and and current
>> latest Testing):
>>
>> -a exit,never -F arch=b64 -S stat -F path=/var/www/server-status -k web
>> -a exit,always -F arch=b64 -S stat -F uid=www-data -F success=0 -k web
>>
>> /var/www/server-status file is non-existant,
>
> Is it a symlink? If it really doesn't exist, then there is no inode to match
> against.

Oh...

No, there is no such file at all, and shouldn’t be, but apache2 tries to check it, hence success=0 case is spammed into 
then logs. Same with .htaccess files that apache2 tries to find in every directory...

I though it is possible to exclude stat calls with that path as argument to the syscall, but if it actually needs 
physical inode... then I guess it makes sense why it does not work for me.

I wanted to _ignore_ some known stat/open failures for non-existant files, to recap.

> What kernel are you using?

3.2 and 3.16 for sure, and I believe I tested on Debian Testing so it should be 4.5 currently.

P.S. should I reply to all or just the list?

Thanks.

--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit

Re: Excluding stat syscall logging for specific path

[Steve Grubb]

On Friday, April 29, 2016 09:16:17 PM Vincas Dargis wrote:
> 2016.04.29 21:00, Steve Grubb rašė:
> > On Friday, April 29, 2016 08:56:26 PM Vincas Dargis wrote:
> >> When playing/learning with auditd, I wanted to log events when apache
> >> fails to access file.
> >> 
> >> Here's the rules I used in Debian Wheezy (same on Jessie and and current
> >> latest Testing):
> >> 
> >> -a exit,never -F arch=b64 -S stat -F path=/var/www/server-status -k web
> >> -a exit,always -F arch=b64 -S stat -F uid=www-data -F success=0 -k web
> >> 
> >> /var/www/server-status file is non-existant,
> > 
> > Is it a symlink? If it really doesn't exist, then there is no inode to
> > match against.
> 
> Oh...
> 
> No, there is no such file at all, and shouldn’t be, but apache2 tries to
> check it, hence success=0 case is spammed into then logs.

Normally ENOENT failures are not a security concern. Normally EACCES and EPERM 
are what attempted security policy violations return with. There is an inode 
in that case.

> Same with
> .htaccess files that apache2 tries to find in every directory...
> 
> I though it is possible to exclude stat calls with that path as argument to
> the syscall, but if it actually needs physical inode... then I guess it
> makes sense why it does not work for me.
> 
> I wanted to _ignore_ some known stat/open failures for non-existant files,
> to recap.

The granularity won't allow it unless you can find another unique attribute to 
weed these out.


> > What kernel are you using?
> 
> 3.2 and 3.16 for sure, and I believe I tested on Debian Testing so it should
> be 4.5 currently.

OK. There were some older kernels where this didn't work right and thought 
that might be relevant. But it turns out that kernel doesn't matter this time.
 
> P.S. should I reply to all or just the list?

Doesn't matter. Mailman usually does the right thing.

-Steve

--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit

Re: Excluding stat syscall logging for specific path

[Vincas Dargis]

2016.04.29 21:48, Steve Grubb rašė:
>> No, there is no such file at all, and shouldn’t be, but apache2 tries to
>> check it, hence success=0 case is spammed into then logs.
>
> Normally ENOENT failures are not a security concern. Normally EACCES and EPERM
> are what attempted security policy violations return with. There is an inode
> in that case.

Yeah, now I am using -S open with EACCES/EPERM as from audit.rules example. Failed stat's ("scans") can actually be seen 
from apache2 error.log.

> But it turns out that kernel doesn't matter this time.

Yes, It's clear for me now.

Thank you!

--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit