-
Notifications
You must be signed in to change notification settings - Fork 30
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
New event: browser extension install #23
Comments
There main reason why I decided to use audit events instead of Note that kernel extensions don't need to be located in one of the directories you name, they can be loaded into the kernel from anywhere. |
Makes sence! I really thought the kernel extensions need to be located there, good to know that this is not the case. But at least for the browser extensions the filesystem events could be used. |
Renaming this issue to reduce the scope to browser extensions. There is issue #16 for kext load events. |
Depends on #26 in order to deliver high quality events |
In addition to the improvements to the filemon core, this needs a thorough analysis of how and where browser extensions, plugins and other add-ons are actually installed for each browser. The above mentioned locations are not the only ways how code is installed in browsers. |
Hi,
Is usually use tools from Patrick Wardle (KnockKnock, BlockBlock, ...) to create events within macos and later on forward them to Splunk. The xnumon looks very promising to replace that workaround for me.
I'm currently missing a couple of thing that could be easily implemented by just extending some parts of your code:
Browser Extensions: Basically browser extensions are just files written to
~/Library/Safari/Extensions
and
~/Library/Application Support/Mozilla/Extensions
~/Library/Application Support/Google/Chrome/External Extensions
I think with your filesystem monitoring this is an easy add-on.
Kernel Extensions
As far as I know these are also located here:
/System/Library/Extensions or /Library/
This should also be extandable by your FS monitoring.
I also looked at your code and I also read a lot about how BlockBlock is implemented. It looks like BlockBlock uses /dev/fsevents. (see https://objective-see.com/products/blockblock.html). Maybe this is an additional way to capture FS events.
The text was updated successfully, but these errors were encountered: