Auditing write syscall

[Richard Guy Briggs]

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...

> > 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.

Tracking the inode could work, but that would have to be dynamic to be
practical, I suspect, and likely the domain of *notify.

> -Steve

- RGB

--
Richard Guy Briggs <rgb at redhat.com>
Sr. S/W Engineer, Kernel Security, Base Operating Systems
Remote, Ottawa, Red Hat Canada
IRC: rgb, SunRaycer
Voice: +1.647.777.2635, Internal: (81) 32635