Auditing write syscall
Steve Grubb
sgrubb at redhat.com
Tue May 14 13:55:55 UTC 2019
Hello,
On Monday, May 13, 2019 3:43:54 PM EDT Ondra N. wrote:
> I would like to ask a question about auditing write syscalls. I am trying
> to monitor all filesystem changes in a specific directory and process the
> changes in near real time - audispd, was very helpful with that.
>
> What concerns me is what if a filedescriptor is kept open for long periods
> of time and written to once in a while? Only the open syscall is logged
> when using a rule like this one.
>
> auditctl -w /tmp/rnd_pop -p wa -k test_key
Right. And if this triggers then you have to assume that the file was modified.
In the past I worked with various upstream projects to have them open a
descriptor read only and reopen when they need to modify files. This cuts down
on false alarms.
> I was thinking that maybe being more explicit about what I want to do could
> help like setting up a rule like this one.
>
> auditctl -a always,exit -F dir=/tmp/rnd_pop -F perm=w -F succes=1 -k
> test_key
>
> But it doesnt seem to work for me, I guess I cannot filter write syscall by
> directory because nothing ever shows up in the audit.log with a rule like
> this.
The directory has to be immediately accessible to the syscall at the time of
the syscall. When open is called, the path is immediately available as it is
one of the syscall parameters. The write only has the FD which does not have
the path associated with the FD accessible. Something in the kernel does keep
this info around as the procfs has path info. But I think it's racey and
could be stale if you have a multithreaded app.
I think there was some reason why this info cannot be used for path
resolution for syscall filtering. I think Paul or Richard may need to answer
why this cannot be used. Perhaps it could be that how do you know in a
generic way based on any given syscall that one parameter is a file descriptor
that can be cross referenced?
> What is the intended way to achieve logging of write syscalls in specific
> directory, am i missing something? Should I check myself if the file is
> still open when event is being processed and act accordingly?
I think some kinds of things will always be just out of reach for the audit
system. Other tools like aide can help fill in the blanks. And there is also
the fanotify interface where detailed change information can be gathered.
-Steve
More information about the Linux-audit
mailing list