EXT :Re: Configuration file monitoring - reporting content changes

[Boyce, Kevin P (AS)]

Not to hijack your thread here, but as long as there might be development in the area of auditing changes to file with aide (sounds like maybe it would be an aide plugin), I would suggest it would also be very nice to know the names of files being copied/burned to removable media.  I don't know how one would accomplish this though.

Kevin

-----Original Message-----
From: linux-audit-bounces at redhat.com [mailto:linux-audit-bounces at redhat.com] On Behalf Of Steve Grubb
Sent: Monday, July 20, 2015 7:08 PM
To: linux-audit at redhat.com; burn at swtf.dyndns.org
Subject: EXT :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

--
Linux-audit mailing list
Linux-audit at redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit