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

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.

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?

On 2019-05-14 09:55, Steve Grubb wrote: > 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.

The FD points to a struct file with struct path that includes a vfsmnt and a dentry/inode, which could be used to create a PATH record, I think.

A hook could be added to the write syscall to store it with audit_file(). Similar hooks would need to be added to other syscalls that read and access and execute FDs to round out that functionality. This is already present for chmod, chown, f*xattr. Having a generic syscall parser that can detect these might be possible, but would probably present an unacceptable performance hit. I do have concerns that it could be racey and stale.

> 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? This is even Al Viro territory...