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 <[email protected]> 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 -- Linux-audit mailing list [email protected] https://www.redhat.com/mailman/listinfo/linux-audit
