You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hello Everyone,
It's a special day! After years of being an Open Source user, today is the first time I'm posting a public GitHub issue to an Open Source project. I'm still figuring out how to best contribute, so please be nice! ;-)
Issue Summary:
In the Linux Operating System, if a file is open with a file descriptor that has write permissions, upon closing that file, an UPDATED action event is triggered in osquery, even though there were no changes made to the original file. This issue can generate numerous false positive osquery UPDATED alerts in certain environments.
Detailed Description:
When a file is opened with write permissions, and closed, the current behavior of inotify in the Linux Kernel is to trigger an IN_CLOSE_WRITE event. That occurs even when no changes are made to that file.
The current behavior of osquery inotify.cpp / kMaskActionsosquery inotify.cpp / kMaskActions is to map theseIN_CLOSE_WRITE events to UPDATED, relying on the IN_CLOSE_WRITE event as if it was an authoritative indicator of file changes.
The Linux Kernel Header for inotify describes the IN_CLOSE_WRITE event as writable file was closed, but it doesn't go as far as saying that the file was modified:
#defineIN_CLOSE_WRITE 0x00000008 /* Writtable file was closed */
This behavior results in numerous false positive events, as applications open files with write permissions, and close these files without any modification.
I'm not sure how to best solve this, so I'm posting here hoping to get some smart eyes on it.
Though I have limited expertise in this codebase, I would be happy to help further review, and validate this issue, and hopefully come up with a solution.
$ rpm -q osquery
osquery-2.6.1-1.linux.x86_64
osquery> select version,build_platform,build_distro from time, osquery_info;
+---------+----------------+--------------+
| version | build_platform | build_distro |
+---------+----------------+--------------+
| 2.6.1 | ubuntu | xenial |
+---------+----------------+--------------+
Operating System Information:
$ cat /etc/redhat-release
CentOS Linux release 7.3.1611 (Core)
$ cat /proc/version
Linux version 3.10.0-514.26.2.el7.x86_64 ([email protected]) (gcc version 4.8.5 20150623 (Red Hat 4.8.5-11) (GCC) ) #1 SMP Tue Jul 4 15:04:05 UTC 2017
Script to Reproduce Events:
(*) Requires the pyinotify module: (pip install pyinotify)
#!/usr/bin/env pythonimportosimporttimeimportpyinotifydefget_inotify_events(notifier):
"""Retrieves acumulated inotify watched events"""assertnotifier._timeoutisnotNone, 'Notifier must have a short timeout'notifier.process_events()
# loop in case more events show up while processingwhilenotifier.check_events():
notifier.read_events()
notifier.process_events()
defmain():
""" Main Program Handler """# Sample file to be watchedfilename="/tmp/testopenrw-nowrites.txt"file=open(filename, "a+")
file.close()
# Creates New Instance of WatchManager to Store Events Being Watchedwatch_manager=pyinotify.WatchManager()
# Add a new watch specific to FILENAME for ALL_EVENTSwatch_manager.add_watch(filename, pyinotify.ALL_EVENTS)
# Associate WatchManager with a Notifier to report and process eventsnotifier=pyinotify.Notifier(watch_manager, timeout=3)
number_of_attempts=5print("Opening %s with RW, and closing without changes %s times..."% (
filename, number_of_attempts))
forcountinrange(number_of_attempts):
print ("\nOpening file(rw), closing file(no writes) #%s"% (count+1))
file=open(filename, "r+")
stattest=os.stat(filename)
print("%s"% (stattest))
file.close()
time.sleep(1)
get_inotify_events(notifier)
if__name__=="__main__":
main()
Additional Information:
The inotify FAQ goes over why we need to track both IN_MODIFY, and IN_CLOSE_WRITE events.
I don't see any mention in the FAQ that IN_CLOSE_WRITE will also be raised when a writable file is closed without modifications.
Notes / Ideas / Possible Workarounds:
This seems to be a combination of something bubbling up from the upstream Linux Kernel implementation of inotify, along with osquery's reliance certain assumptions of the inotify behavior.
On the osquery side, I've seen hundreds of thousands of these UPDATED events, some with completely the same exact message, and others with just the timestamp changed even though no changes were made.
There may be a workaround in creating a sql query that would minimize the display repeated false positive events.
Figure out additional logic that would compare a IN_CLOSE_WRITE event with a previous similar event, if any, and determine whether there was an actual change. If there was an actual change the IN_CLOSE_WRITE reference in osquery inotify.cpp / kMaskActionsosquery inotify.cpp / kMaskActions would conditionally map to something like UPDATED if a change can be confirmed, or CLOSED if no change was made.
The text was updated successfully, but these errors were encountered:
Hello Everyone,
It's a special day! After years of being an Open Source user, today is the first time I'm posting a public GitHub issue to an Open Source project. I'm still figuring out how to best contribute, so please be nice! ;-)
Issue Summary:
In the Linux Operating System, if a file is open with a file descriptor that has write permissions, upon closing that file, an
UPDATED
action event is triggered in osquery, even though there were no changes made to the original file. This issue can generate numerous false positive osqueryUPDATED
alerts in certain environments.Detailed Description:
When a file is opened with write permissions, and closed, the current behavior of
inotify
in the Linux Kernel is to trigger anIN_CLOSE_WRITE
event. That occurs even when no changes are made to that file.The current behavior of
osquery inotify.cpp / kMaskActionsosquery inotify.cpp / kMaskActions is to map theseIN_CLOSE_WRITE
events toUPDATED
, relying on theIN_CLOSE_WRITE
event as if it was an authoritative indicator of file changes.The Linux Kernel Header for inotify describes the
IN_CLOSE_WRITE
event as writable file was closed, but it doesn't go as far as saying that the file was modified:This behavior results in numerous false positive events, as applications open files with write permissions, and close these files without any modification.
I'm not sure how to best solve this, so I'm posting here hoping to get some smart eyes on it.
Though I have limited expertise in this codebase, I would be happy to help further review, and validate this issue, and hopefully come up with a solution.
Keywords:
Tested osquery Version:
Operating System Information:
Script to Reproduce Events:
(*) Requires the
pyinotify
module: (pip install pyinotify
)Script Output:
Sample OS Query logs from /var/log/osquery/osqueryd.results.log:
Additional Information:
The inotify FAQ goes over why we need to track both
IN_MODIFY
, andIN_CLOSE_WRITE
events.I don't see any mention in the FAQ that
IN_CLOSE_WRITE
will also be raised when a writable file is closed without modifications.Notes / Ideas / Possible Workarounds:
UPDATED
events, some with completely the same exact message, and others with just the timestamp changed even though no changes were made.IN_CLOSE_WRITE
event with a previous similar event, if any, and determine whether there was an actual change. If there was an actual change theIN_CLOSE_WRITE
reference inosquery inotify.cpp / kMaskActionsosquery inotify.cpp / kMaskActions would conditionally map to something likeUPDATED
if a change can be confirmed, orCLOSED
if no change was made.The text was updated successfully, but these errors were encountered: