Configuration file monitoring - reporting content changes
Burn Alting
burn at swtf.dyndns.org
Tue Jul 21 21:54:23 UTC 2015
On Tue, 2015-07-21 at 13:59 -0400, Steve Grubb wrote:
> 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
I suppose one could follow tail(1)'s lead and monitor via a combination
of inotify() supplemented by file, path and inode monitoring as well.
Perhaps not elegant, but it may do the job.
Burn
More information about the Linux-audit
mailing list