AutomaticResponseSink

1. Overview

The AutomaticResponseSink.cpp implementation decorates the event pipeline with asynchronous system-service containment. It reacts only after the kernel has already blocked a qualifying protected metadata operation, then emits a follow-up event describing whether service containment succeeded.

The file integrates the following components, APIs, or runtime concepts:

  • IEventSink
  • SystemServiceControl
  • std::thread
  • condition_variable

2. Actionable Event Gate

Automatic containment is considered only for permission, owner, xattr, ACL, protected unlink/rename/hardlink, or integrity-drift events, and only when the verdict is exactly RG_VERDICT_BLOCKED. Audit and alert events never trigger a state-changing service action.


3. Downstream-First Delivery

onEvent() first forwards the original event to the downstream sink. It then checks the atomic auto-block setting, the actionable-event gate, and whether the affected filename maps to a recognized system service definition.


4. Asynchronous Queue

Recognized service paths are normalized and deduplicated in queuedPaths_. A worker thread waits on a condition variable, removes one pending service, calls blockSystemService(), emits a result event, and finally removes the path from the deduplication set.


5. Containment Safety Rationale

The source explicitly relies on the fact that the LSM has already denied the metadata modification. Therefore the service definition remains unchanged when the worker later stops the service, avoiding execution of attacker-replaced content as part of this response path.


6. Follow-Up Event

emitServiceResult() copies the triggering event, changes the type to RG_EVENT_SERVICE_BLOCKED, uses BLOCKED on success or ALERT on failure, sets comm to rootguard-react, and forwards the result downstream.


7. Runtime and Security Considerations

  • Enforcement-only reaction: no automatic containment occurs for audit/alert records.
  • Worker isolation: service control cannot stall the BPF callback thread.
  • Duplicate suppression: the same normalized service path cannot be queued multiple times concurrently.
  • Exception containment: reaction errors never terminate RootGuard.