From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steve Grubb Subject: Re: Configuration file monitoring - reporting content changes Date: Mon, 20 Jul 2015 19:08:01 -0400 Message-ID: <7607942.YQGEPIT7XG@x2> References: <1437393227.26354.16.camel@swtf.swtf.dyndns.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1437393227.26354.16.camel@swtf.swtf.dyndns.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: linux-audit@redhat.com, burn@swtf.dyndns.org List-Id: linux-audit@redhat.com 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