On Monday, July 20, 2015 09:53:47 PM Burn Alting wrote: > I am interested in any Linux based capability that will monitor > identified files and report on actual changes to the monitored file.
I know of nothing that does this. But as long as the list of files is limited, it doesn't sound like a hard program to write. > I know there are methods of recording that the file has been changed (e.g. > aide and/or monitor writes via auditd), but I want to know what has > changed ... basically something that would provide a 'diff' like output. > > Now there are tools like Samhain that will record the content changes of > a file that is <= 92000 bytes in size, but I am interested in a more > lightweight solution ... perhaps a simple inotify(7) based utility that > perhaps maintains a copy of the file(s) in core (in compressed format) > and based on inotify() returns checks for changes and reports (somehow > yet to be defined) the before/after changes. It would have to be after the changes since inotify would tell you something happened. > Is there anything 'out there' that list members are aware of? > > If not, would the following utility be of interest? I am certain there are people that are interested in this even if no one is speaking up on it. > On startup, load the monitored file(s) (saving a compressed copy in memory). > Then, using inotify, monitor for changes and if so, emit some kind of record > defining the change and change the compressed in-memory copy. If so, is > our mailing list and the contributed portion of auditd an appropriate > repository for such a tool. That's an interesting question. > Naturally, such a tool would be supported by appropriate auditd > monitoring that will take care of changing file attributes etc and file > writes. That is, auditd tells me who and the utility tells me what. Correlating the changes might be interesting. There can be a long time between opening a file and closing it. The inotify might trigger on the changes during flushing to disk. Or what if the file was mmap'ed? I don't know if that would be caught. But there's only 1 way to find out. :-) Like I said, I think its a straight forward program to write. No one's specifically asked for this. But we tap dance around the subject by patching programs to record what is being changed (shadow-utils). So, there is a precedence that this is needed. But Common Criteria makes it only for trusted databases. One file you would exempt, I presume, is /etc/shadow and /etc/gshadow. Any one else with an opinion? -Steve -- Linux-audit mailing list [email protected] https://www.redhat.com/mailman/listinfo/linux-audit
