Improve file monitoring core

[droe]

Current file monitoring based on AUE_CLOSE and other audit events has a number of issues that need a solution. Think about reimplementing or improving the event acquisition. Options include:

• fsevents: Regular API does not supply pid, direct access to special device is not supported by apple and seems to cause issues if not done correctly; also requires event sync across two APIs, i.e. to keep processes around for a while until all fsevents for a pid have arrived, queue fsevents arriving before fork and exec for pid arrived via audit(4). Unfortunately, fsevents (both via API and natively) does not supply any timestamp, so the best timestamp we can do is in userspace after receiving a batch of events. This can serve as an upper time bound to locate the matching image that was loaded in the process that pid points to, but it is not sufficient to generally map file system events to a specific exec image.
• kqueue: Lose process context, but lightweight and no impact on audit event drops. Can we convince Apple to implement NOTE_CLOSE and NOTE_CLOSE_WRITE like FreeBSD for what would be the most lightweight solution?
• audit(4): Get Apple to add events for implicit close at exit, or track open files per process based on open events, and attempt to handle all syscalls properly. Syscalls like copyfile are problematic since they allow recursive copies. Also problematic is the presence of many audit(4) bugs that lead to unresolved destination path tokens - when they point to symlinks and/or are relative, it is impossible to determine the destination reliably.
• kext KAuth vnode: Acquire this event in-kernel using KAUTH_VNODE_WRITE_DATA a.k.a. KAUTH_VNODE_ADD_FILE. Sync of events with execs would be reliable since they already pass through the kext via KAuth too. Still requires processing of event to wait until file is closed or process exits, so advantage is primarily resistance vs audit drops.
• kext KAuth fileop: Acquire this event in-kernel using KAUTH_FILEOP_CLOSE et al. Events are directly actionable, but lack actor context. Context may be added by combining vnode and fileop within the kext or in userspace. Are the latter also triggered on implicit close during exit?

Best intermediate solution is audit(4) with open tracking, but it involves an impractical amount of audit(4) events and tracking open file descriptors.

Most viable long-term solution is kext-based, requiring a signed kext (#6), because there is no trivial strategy to handle the no kext case gracefully.

If loss of process context is acceptable, fsevents via API is the winner; this might be a viable no-kext strategy if we want to abandon audit(4) based file tracking.

[droe]

The full solution depends on #6, marking this blocked. Might write a replacement using audit(4) but that involves tracking an awful amount of file events, creating a much bigger performance impact than a kext-based solution.