From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steve Grubb Subject: Re: Configuration file monitoring - reporting content changes Date: Tue, 21 Jul 2015 13:59:01 -0400 Message-ID: <3307081.aEimE15yPr@x2> References: <1437393227.26354.16.camel@swtf.swtf.dyndns.org> <7607942.YQGEPIT7XG@x2> <55AE5967.70609@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <55AE5967.70609@redhat.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: John Dennis Cc: linux-audit@redhat.com List-Id: linux-audit@redhat.com On Tuesday, July 21, 2015 10:38:31 AM John Dennis wrote: > On 07/20/2015 07:08 PM, Steve Grubb wrote: > > 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. > > > > Any one else with an opinion? > > Yes :-) I'm not so sure it's an easy program to write and be robust in a > variety of scenarios. I know because I wrote such a program once. The > basic problem is most people think in terms of monitoring a file by name > (e.g. it's pathname). But inotify operates on inodes, not filenames. If > that file is subject to any variety of log rotation strategies or > modifications by a configuration manager whereby the file is renamed or > moved to a different directory then any program using inotify to monitor > the file needs to become reasonably sophisticated and be able to track > those changes. It is entirely possible for two processes to have opened > the same file by name but have them be 2 different files (e.g. after > opening the file path is modified but the process still has the original > inode open, now a 2nd process opens the same filename but gets a > different inode). Conflating inodes with filenames can lead to > unexpected results and if the purpose is some sort of security > monitoring it will be important these issues are accounted for. I recently was doing some experimenting with the fanotify API. In my mind, I think its likely to be better. But it has limitations such as mmap'ed file may not generate a modify event. So, if I were going to do it, I'd start there. But you do raise a whole lot of good points. My guess is this would watch config files which logrotate wouldn't apply. But yes, editors do open a temp copy and then do a rename. In my experimenting, I didn't bother to see how fanotify handle renames. (You would think its a modify event.) -Steve > Some of this is discussed in these documents which accompany the lwatch > (Log Watch) program I wrote: > > https://jdennis.fedorapeople.org/lwatch/html/InotifyOverview.html > https://jdennis.fedorapeople.org/lwatch/html/LogWatchOverview.html