Skip to content
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

Open
losandros opened this issue Jul 4, 2018 · 5 comments
Open

New event: browser extension install #23

losandros opened this issue Jul 4, 2018 · 5 comments
Labels
status:blocked depends on other unresolved issue, github or external type:feature request for additional functionality

Comments

@losandros
Copy link

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:

  1. 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.

  2. 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.

@droe droe added the type:feature request for additional functionality label Jul 4, 2018
@droe
Copy link
Owner

droe commented Jul 4, 2018

There main reason why I decided to use audit events instead of /dev/fsevents for filesystem monitoring so far was that audit events are synchronous in relation to process events. Synchronizing events from multiple sources is tricky to implement well. However, it's something that I wanted to eventually look into.

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.

@losandros
Copy link
Author

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.

@droe
Copy link
Owner

droe commented Jul 5, 2018

Renaming this issue to reduce the scope to browser extensions. There is issue #16 for kext load events.

@droe droe changed the title Extend Filesystem Monitoring to Browser Extensions and Kernel Extensions Extend Filesystem Monitoring to Browser Extensions Jul 5, 2018
@droe
Copy link
Owner

droe commented Jul 15, 2018

Depends on #26 in order to deliver high quality events

@droe droe changed the title Extend Filesystem Monitoring to Browser Extensions New event: browser extension install Jul 23, 2018
@droe droe added the status:analysis-needed solution unclear, needs analysis by a developer label Jul 24, 2018
@droe
Copy link
Owner

droe commented Jul 24, 2018

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.

@droe droe added status:blocked depends on other unresolved issue, github or external and removed status:analysis-needed solution unclear, needs analysis by a developer labels Aug 1, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status:blocked depends on other unresolved issue, github or external type:feature request for additional functionality
Projects
None yet
Development

No branches or pull requests

2 participants