Steve,
Thanks for the prompt reply.
For anyone else who may find this useful, the files were served over NFS
using automount. When the mounts are dropped, the rules get deleted.
Cheers
John
On Mon, May 20, 2013 at 2:58 PM, Steve Grubb <sgrubb(a)redhat.com> wrote:
On Monday, May 20, 2013 11:04:30 AM John Barnes wrote:
> I set up 4 simple audit rules using audictl:
>
> auditctl -w "/path/to/my/bin0" -p x
> auditctl -w "/path/to/my/bin1" -p x
>
> The rules were applied and show in auditctl -l. I tested them and
> they successfully log the execution of both binaries.
>
> However the rules were mysteriously flushed with only
> the following available in ausearch -m CONFIG_CHANGE:
>
> time->Sat May 18 00:03:19 2013
>
> type=CONFIG_CHANGE msg=audit(1368831799.081:466947): auid=4294967295
> ses=4294967295 op="remove rule" path="/path/to/my/bin0"
key=(null) list=4
> res=1
>
> time->Sat May 18 00:03:19 2013
>
> type=CONFIG_CHANGE msg=audit(1368831799.081:466948): auid=4294967295
> ses=4294967295 op="remove rule" path="/path/to/my/bin1"
key=(null) list=4
> res=1
>
> The uid doesn't match any known user so I presume these are initiated by
> the kernel.
Yes, these are -1, which is unset. This event is created by the kernel.
> The system wasn't under any pressure at the time (mem/load
> average fine), there was plenty of disk space available in all volumes,
and
> the auditd was not restarted and the logs were not rotated.
>
> Is there anything that can cause the rules to be flushed in this way?
It's
> a little concerning that they've just disappeared.
I think if your file is deleted, then it removes the associated rule.
-Steve