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