Kevin, I believe there may be some work in this space occurring in the not too distant future.
Regards On Tue, 2015-07-21 at 13:47 +0000, Boyce, Kevin P (AS) wrote: > Not to hijack your thread here, but as long as there might be development in > the area of auditing changes to file with aide (sounds like maybe it would be > an aide plugin), I would suggest it would also be very nice to know the names > of files being copied/burned to removable media. I don't know how one would > accomplish this though. > > Kevin > > -----Original Message----- > From: [email protected] [mailto:[email protected]] > On Behalf Of Steve Grubb > Sent: Monday, July 20, 2015 7:08 PM > To: [email protected]; [email protected] > Subject: EXT :Re: Configuration file monitoring - reporting content changes > > 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 -- Linux-audit mailing list [email protected] https://www.redhat.com/mailman/listinfo/linux-audit
