We keep hitting a wall with FIM. If we monitor directories we end up having to create too many system specific excludes as there is usually a noisy file in the directories that is application specific. If we monitor specific files directly with inotify, when vi or something else changes it, you now no longer have a file monitor on it. Would it be feasible to add some type of setting to the inotify method to set a new watch on a file after x amount of time, so it can catch repeated changes to a file?

yes, and doing MD5,SHA1,SHA256 for every CREATE|UPDATE of a file is a killer.

Generally we are trying to set specific watches on files that should not be changed often. We just have no way of restarting Osq after each event, so after a single vi write, we have lost fim.

what do you mean by "need to restart osq after each event"?

If you monitor say, /etc/hosts with no wildcards using inotify.

That sounds like a bug in either osquery FIM or inotify. You should get an event for every update of a monitored file.

Its no longer the same inode, its not a bug, its because vi creates a new file instead of in place edit.

often you get double events for each change...

With nano, it edits in place and you will not see that effect.

And FIM is relying on an open file handle... so it's a bug in FIM

Thats basically what I am looking to have happen, but currently it does not.

Also an issue if you want to monitor /etc/apache/file, but /etc/apache did not exist at osquery startup... won't get watched.

thats correct, if you watch using wildcards, it does see the new files

If you have time, please file an issue on FIM, this is probably not being considered.

I did a year or so ago, ended up adding a note to the docs so others know, but considered expected.

Is the issue you filed closed?

Yes

As a security solution, I don't see documenting as a sufficient resolution. Seems like an easy osquery FIM bypass by editing /etc/hosts by adding a space character, then editing again with malicious intent. I will take a closer look.

There would have to be some consideration for the timing on the new watch. The new file could not get written for quite some time.

yes

CentOS 6.10 kernel 2.6.32-754