public inbox for linux-audit@redhat.com
 help / color / mirror / Atom feed
* auditd on nonexistent files
@ 2015-09-14 16:01 Davíð Steinn Geirsson
  2015-09-15  9:15 ` Steve Grubb
  0 siblings, 1 reply; 6+ messages in thread
From: Davíð Steinn Geirsson @ 2015-09-14 16:01 UTC (permalink / raw)
  To: linux-audit


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

Hi all,

What is the best practice for using auditd for file integrity monitoring?

From the documentation, I have this, which works fine:
-a always,exit -F dir=/bin -F perm=wa

However, it seems that if I have a rule on a nonexistent directory,
auditd will fail to add the rule (I assume because it's adding a watch
on an inode or something like that?), but it will also just stop reading
audit.rules and not add any subsequent rules.

This is bad in an environment where we have to have FIM for critical
application files, but where another team may be maintaining some of the
apps and therefore might remove some watched directories, especially as
their mishaps may impact auditing for other parts of the system.


Can something be done to get better behaviour here?

I see two ways it could be better
1) (the ideal case) auditd will add rules even for nonexistent
directories, and when they are created will add a watch for them. If a
directory is removed and another created with the same name, auditd will
add a watch on the new directory.

2) auditd still cannot add watches to nonexistent directories, but a
failed rule add from audit.rules will become a warning rather than an
error so subsequent watches still get added.

I suspect 1) is not possible, but can I get auditd to behave like in 2)?

Best regards,
Davíð


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

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



^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: auditd on nonexistent files
  2015-09-14 16:01 auditd on nonexistent files Davíð Steinn Geirsson
@ 2015-09-15  9:15 ` Steve Grubb
  2015-09-15  9:25   ` Davíð Steinn Geirsson
  2015-09-15 10:07   ` Richard Guy Briggs
  0 siblings, 2 replies; 6+ messages in thread
From: Steve Grubb @ 2015-09-15  9:15 UTC (permalink / raw)
  To: Davíð Steinn Geirsson; +Cc: linux-audit

On Mon, 14 Sep 2015 16:01:17 +0000
Davíð Steinn Geirsson <dsg@sensa.is> wrote:

> Hi all,
> 
> What is the best practice for using auditd for file integrity
> monitoring?
> 
> From the documentation, I have this, which works fine:
> -a always,exit -F dir=/bin -F perm=wa
> 
> However, it seems that if I have a rule on a nonexistent directory,
> auditd will fail to add the rule (I assume because it's adding a watch
> on an inode or something like that?), but it will also just stop
> reading audit.rules and not add any subsequent rules.
> 
> This is bad in an environment where we have to have FIM for critical
> application files, but where another team may be maintaining some of
> the apps and therefore might remove some watched directories,
> especially as their mishaps may impact auditing for other parts of
> the system.
> 
> 
> Can something be done to get better behaviour here?
> 
> I see two ways it could be better
> 1) (the ideal case) auditd will add rules even for nonexistent
> directories, and when they are created will add a watch for them. If a
> directory is removed and another created with the same name, auditd
> will add a watch on the new directory.

Which kernel are you using? I want to think this was fixed in kernels
around 2.6.36 or later. This original problem was that the audit
watches are based on inotify which needs an inode. If there's no inode,
you can't place the watch.


> 2) auditd still cannot add watches to nonexistent directories, but a
> failed rule add from audit.rules will become a warning rather than an
> error so subsequent watches still get added.

Check into adding -i or -c near the top of your rules.

-Steve


> I suspect 1) is not possible, but can I get auditd to behave like in
> 2)?
> 
> Best regards,
> Davíð
> 


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

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: auditd on nonexistent files
  2015-09-15  9:15 ` Steve Grubb
@ 2015-09-15  9:25   ` Davíð Steinn Geirsson
  2015-09-15 10:07   ` Richard Guy Briggs
  1 sibling, 0 replies; 6+ messages in thread
From: Davíð Steinn Geirsson @ 2015-09-15  9:25 UTC (permalink / raw)
  To: Steve Grubb; +Cc: linux-audit


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

Hi,

On 09/15/2015 09:15 AM, Steve Grubb wrote:
> On Mon, 14 Sep 2015 16:01:17 +0000
> Davíð Steinn Geirsson <dsg@sensa.is> wrote:
> 
>> Hi all,
>>
>> What is the best practice for using auditd for file integrity
>> monitoring?
>>
>> From the documentation, I have this, which works fine:
>> -a always,exit -F dir=/bin -F perm=wa
>>
>> However, it seems that if I have a rule on a nonexistent directory,
>> auditd will fail to add the rule (I assume because it's adding a watch
>> on an inode or something like that?), but it will also just stop
>> reading audit.rules and not add any subsequent rules.
>>
>> This is bad in an environment where we have to have FIM for critical
>> application files, but where another team may be maintaining some of
>> the apps and therefore might remove some watched directories,
>> especially as their mishaps may impact auditing for other parts of
>> the system.
>>
>>
>> Can something be done to get better behaviour here?
>>
>> I see two ways it could be better
>> 1) (the ideal case) auditd will add rules even for nonexistent
>> directories, and when they are created will add a watch for them. If a
>> directory is removed and another created with the same name, auditd
>> will add a watch on the new directory.
> 
> Which kernel are you using? I want to think this was fixed in kernels
> around 2.6.36 or later. This original problem was that the audit
> watches are based on inotify which needs an inode. If there's no inode,
> you can't place the watch.

The machines I'm working with are RHEL6 with 2.6.32, but I just tried
with a machine with a 3.18 kernel and got the same behaviour.

> 
> 
>> 2) auditd still cannot add watches to nonexistent directories, but a
>> failed rule add from audit.rules will become a warning rather than an
>> error so subsequent watches still get added.
> 
> Check into adding -i or -c near the top of your rules.

Thanks, that helps for a workaround. Not sure how I missed that in the
manpage.


> 
> -Steve
> 
> 
>> I suspect 1) is not possible, but can I get auditd to behave like in
>> 2)?
>>
>> Best regards,
>> Davíð
>>
> 


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

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



^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: auditd on nonexistent files
  2015-09-15  9:15 ` Steve Grubb
  2015-09-15  9:25   ` Davíð Steinn Geirsson
@ 2015-09-15 10:07   ` Richard Guy Briggs
  2015-09-16  7:56     ` Florian Crouzat
  1 sibling, 1 reply; 6+ messages in thread
From: Richard Guy Briggs @ 2015-09-15 10:07 UTC (permalink / raw)
  To: Steve Grubb; +Cc: linux-audit

On 15/09/15, Steve Grubb wrote:
> On Mon, 14 Sep 2015 16:01:17 +0000
> Davíð Steinn Geirsson <dsg@sensa.is> wrote:
> 
> > Hi all,
> > 
> > What is the best practice for using auditd for file integrity
> > monitoring?
> > 
> > From the documentation, I have this, which works fine:
> > -a always,exit -F dir=/bin -F perm=wa
> > 
> > However, it seems that if I have a rule on a nonexistent directory,
> > auditd will fail to add the rule (I assume because it's adding a watch
> > on an inode or something like that?), but it will also just stop
> > reading audit.rules and not add any subsequent rules.
> > 
> > This is bad in an environment where we have to have FIM for critical
> > application files, but where another team may be maintaining some of
> > the apps and therefore might remove some watched directories,
> > especially as their mishaps may impact auditing for other parts of
> > the system.
> > 
> > Can something be done to get better behaviour here?
> > 
> > I see two ways it could be better
> > 1) (the ideal case) auditd will add rules even for nonexistent
> > directories, and when they are created will add a watch for them. If a
> > directory is removed and another created with the same name, auditd
> > will add a watch on the new directory.
> 
> Which kernel are you using? I want to think this was fixed in kernels
> around 2.6.36 or later. This original problem was that the audit
> watches are based on inotify which needs an inode. If there's no inode,
> you can't place the watch.

A watch can be added for a file that does not exist while the containing
directory does, but a directory that does not exist (when the containing
directory does not exist) does not work.

> > 2) auditd still cannot add watches to nonexistent directories, but a
> > failed rule add from audit.rules will become a warning rather than an
> > error so subsequent watches still get added.
> 
> Check into adding -i or -c near the top of your rules.
> 
> -Steve
> 
> > I suspect 1) is not possible, but can I get auditd to behave like in
> > 2)?

1) is not currently implemented, but is worth discussing.

> > Davíð

- RGB

--
Richard Guy Briggs <rbriggs@redhat.com>
Senior Software Engineer, Kernel Security, AMER ENG Base Operating Systems, Red Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635, Alt: +1.613.693.0684x3545

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: auditd on nonexistent files
  2015-09-15 10:07   ` Richard Guy Briggs
@ 2015-09-16  7:56     ` Florian Crouzat
  2015-09-18  0:22       ` Steve Grubb
  0 siblings, 1 reply; 6+ messages in thread
From: Florian Crouzat @ 2015-09-16  7:56 UTC (permalink / raw)
  To: linux-audit

On 09/15/2015 12:07 PM, Richard Guy Briggs wrote:
> On 15/09/15, Steve Grubb wrote:
>> On Mon, 14 Sep 2015 16:01:17 +0000
>> Davíð Steinn Geirsson <dsg@sensa.is> wrote:
>>
>>> Hi all,
>>>
>>> What is the best practice for using auditd for file integrity
>>> monitoring?
>>>
>>> From the documentation, I have this, which works fine:
>>> -a always,exit -F dir=/bin -F perm=wa
>>>
>>> However, it seems that if I have a rule on a nonexistent directory,
>>> auditd will fail to add the rule (I assume because it's adding a watch
>>> on an inode or something like that?), but it will also just stop
>>> reading audit.rules and not add any subsequent rules.
>>>
>>> This is bad in an environment where we have to have FIM for critical
>>> application files, but where another team may be maintaining some of
>>> the apps and therefore might remove some watched directories,
>>> especially as their mishaps may impact auditing for other parts of
>>> the system.
>>>
>>> Can something be done to get better behaviour here?
>>>
>>> I see two ways it could be better
>>> 1) (the ideal case) auditd will add rules even for nonexistent
>>> directories, and when they are created will add a watch for them. If a
>>> directory is removed and another created with the same name, auditd
>>> will add a watch on the new directory.
>>
>> Which kernel are you using? I want to think this was fixed in kernels
>> around 2.6.36 or later. This original problem was that the audit
>> watches are based on inotify which needs an inode. If there's no inode,
>> you can't place the watch.
> 
> A watch can be added for a file that does not exist while the containing
> directory does, but a directory that does not exist (when the containing
> directory does not exist) does not work.
> 
>>> 2) auditd still cannot add watches to nonexistent directories, but a
>>> failed rule add from audit.rules will become a warning rather than an
>>> error so subsequent watches still get added.
>>
>> Check into adding -i or -c near the top of your rules.
>>
>> -Steve
>>
>>> I suspect 1) is not possible, but can I get auditd to behave like in
>>> 2)?
> 
> 1) is not currently implemented, but is worth discussing.
> 
>>> Davíð

I asked the same question in the "Watching over non-existent folder to
maintain a generic audit.rules file" thread but got different hints.
I've been directed to augenrules which could help but this doesn't
really match or facilitate my needs to replace my current FIM tool by
auditd which requires me to write a generic configuration with all
possibles folders (including applicative ones) and deploy accross all
hosts without knowing which host runs which app and/or contains which
folders.

I guess I'll stick by this thread now.
Have you tried the -i or -c hint ?

Florian


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

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: auditd on nonexistent files
  2015-09-16  7:56     ` Florian Crouzat
@ 2015-09-18  0:22       ` Steve Grubb
  0 siblings, 0 replies; 6+ messages in thread
From: Steve Grubb @ 2015-09-18  0:22 UTC (permalink / raw)
  To: Florian Crouzat; +Cc: linux-audit

On Wed, 16 Sep 2015 09:56:58 +0200
Florian Crouzat <tech@floriancrouzat.net> wrote:
> I asked the same question in the "Watching over non-existent folder to
> maintain a generic audit.rules file" thread but got different hints.
> I've been directed to augenrules which could help but this doesn't
> really match or facilitate my needs to replace my current FIM tool by
> auditd which requires me to write a generic configuration with all
> possibles folders (including applicative ones) and deploy accross all
> hosts without knowing which host runs which app and/or contains which
> folders.

That is not the intended way to use augenrules. The intention is to have
a base set of rules that apply to everything. Then drop in rules that
apply to that type of system. IOW, you would not put apache rules
on your DNS system because that doesn't make sense.

-Steve

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2015-09-18  0:22 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2015-09-14 16:01 auditd on nonexistent files Davíð Steinn Geirsson
2015-09-15  9:15 ` Steve Grubb
2015-09-15  9:25   ` Davíð Steinn Geirsson
2015-09-15 10:07   ` Richard Guy Briggs
2015-09-16  7:56     ` Florian Crouzat
2015-09-18  0:22       ` Steve Grubb

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox