feat(macos): process and file telemetry via Endpoint Security

[mostafa]

Summary

Adds the macOS Endpoint Security sensor and wires it into the runtime in place of the placeholder. Process and file events map into the shared event model with Sysmon-compatible identifiers, so existing Sigma, YARA, and IOC detection works on macOS process and file activity.

• Add the endpoint-sec dependency and an EsfSensor that owns the ES client on a dedicated thread and surfaces client init failures (not root, missing entitlement, TCC denial) synchronously.
• Map process exec and exit: executable path, arguments, pid, parent pid, working directory, user, and a pid plus start-time key.
• Map file create, delete, rename, and modify (modify is derived from close-after-write to keep the high-volume close stream down to real content changes).
• Add the Endpoint Security entitlement plist and document ad-hoc signing and SIP requirements for local builds.

Process and file events emit the raw uid and defer username resolution to the normalizer, matching the Linux sensor.

Type of change

• feat / enhancement - new feature

Test plan

• Tested on Windows
• Tested on Linux
• Tested on macOS: unit tests for the event mappings, plus an ECS contract test for file events
• Existing tests pass (cargo test)
• New tests added (exec, exit, file mappings and ECS contract)

Note for maintainers: creating an Endpoint Security client requires root and the com.apple.developer.endpoint-security.client entitlement on signed and notarized builds. For local testing you can run with SIP and AMFI relaxed. The live client path was exercised manually under those conditions; the mappings are covered by unit tests.

Checklist

• Label added to this PR
• Docs updated (if behaviour changed)

Notes

Second of four in the #41 series, on top of #42 (merged). Verified on macOS arm64: cargo fmt --check, cargo clippy --locked --all-targets -- -D clippy::all, and cargo test --locked (134 passed) are all clean.

Part of #41.

[Karib0u]

Thanks for this — the threading model (client created/dropped on a dedicated thread, NOTIFY-only subscriptions, non-blocking try_send with drop-on-full) and the FFI-free RawExec/RawFile split are clean and genuinely testable. Two things I'd like addressed before merge (both verified against the Linux sensor), plus a couple of minor notes inline.

[Karib0u]

File-modify event_id doesn't match the Linux sensor — breaks Sigma parity.

This maps modify to EVENT_ID_FILE_CHANGE (65), but the Linux sensor maps modify to event_id 11 with action_code 65 (linux/events.rs:207 → 4 => (SensorAction::Modify, 11, 65)). Create/delete/rename all match Linux exactly; only modify diverges, and the value 65 is identical to its own action_code — which looks like the event_id was set to the action_code by mistake.

This matters because Sigma matches EventID against event_id_string (models/event.rs:84), with no downstream remap (ECS event.action keys on action_code instead, which is why the ECS contract test passes). Sysmon has no dedicated file-modify event, so file-change detections key on EventID: 11 — a rule that fires on Linux modify will silently not fire on macOS modify, contradicting the PR's claim that existing Sigma detection works.

Suggested fix:

FileAction::Modify => (SensorAction::Modify, EVENT_ID_FILE_CREATE, 65), // 11, matching Linux

The test at line ~626 currently asserts event_id == EVENT_ID_FILE_CHANGE, so it locks in the wrong value — worth updating it to assert 11 so the parity is enforced.

[mostafa]

Addressed in 913f850.

[Karib0u]

Per-event getpwuid_r on the file hot path.

actor() calls resolved_user(token.ruid()) → lookup_username_by_uid, which runs sysconf + getpwuid_r (a Directory Services / opendirectoryd lookup on macOS) and allocates a buffer on every event — including every unlink and every modified close, both high-volume. This runs inside the mapping on ES's dispatch queue, so under heavy file activity it risks the handler falling behind and events being dropped via the try_send-full path.

The Linux sensor avoids this entirely on the file path — it passes the raw uid.to_string() and never does a directory lookup (resolve_user_field in the normalizer only resolves Windows S-1- SIDs, so it's a no-op for macOS uids).

Suggestion: memoize uid→username (a small Mutex<HashMap<u32, String>>), or defer resolution downstream the way Linux does. (Minor: for create/rename the destination()? early-return runs before actor(), so those skip the lookup when there's no destination — but unlink and modified-close still hit it unconditionally.)

[mostafa]

Addressed in 34757d2.

[mostafa]

Thanks, both good catches. Addressed against events.rs as the canonical Linux behavior:

1. File-modify event id parity (913f850)
You're right, the event id was mistakenly set to the action code. Modify now reports under EVENT_ID_FILE_CREATE (11) with action code 65, matching linux/events.rs:207. The test now asserts 11 so the parity is locked in.

2. Per-event getpwuid_r on the file hot path (34757d2)
Switched the sensor to emit the raw uid.to_string() for process and file events and defer username resolution to the normalizer, exactly like events.rs (which uses event.uid.to_string() for process, network, and file). This removes the directory-services lookup from Endpoint Security's dispatch queue entirely, so unlink and modified-close no longer risk the handler falling behind. I went with deferral rather than memoization to keep parity with the Linux sensor. lookup_username_by_uid is back to Linux-only since the macOS sensor no longer calls it.

Verified on macOS arm64: cargo fmt --all -- --check, cargo clippy --locked --all-targets -- -D clippy::all, and cargo test --locked (134 passed) are all clean.