Configuration file monitoring - reporting content changes

[Steve Grubb]

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