Dosu Logo
Home
Documents
Architecture Overview
Architecture Overview
Type
External
Status
Published
Created
Mar 8, 2026
Updated
Apr 3, 2026
Updated by
Dosu Bot

Three-Component Security Architecture#

DaemonEye utilizes a workspace-based architecture featuring multiple crates and binaries, employing feature flags for precise dependency management. Its security model is built on a three-component design, emphasizing strict privilege separation to ensure continuous process monitoring and threat detection. The system prioritizes a minimal attack surface while maintaining high performance and audit-grade integrity.
The foundational element of this architecture is the collector-core framework. This framework delivers an extensible collection infrastructure for various monitoring components, all operating on a shared operational base. For in-depth information on the underlying collection infrastructure, refer to the Collector-Core Framework documentation.

Overview#

DaemonEye employs a modular architecture built around three tightly scoped components, supported by a shared core library and verifiable data stores. Each component operates under the principle of least privilege, ensuring secure and auditable data flow from collection to alert delivery.

ProcMond --- Privileged Collector#

ProcMond (Process Monitoring Collector) is a minimalist, high-privilege component designed for process collection and integrity verification. It operates without network access, communicating solely via local Inter-Process Communication (IPC).
Core Modules:

  • Process Monitor (PM): Enumerates system processes and gathers essential metadata, including Process ID (PID), Parent Process ID (PPID), command line arguments, and executable path.
  • Hash Computer (HC): Calculates SHA-256 checksums of executable binaries to validate their integrity.
  • Audit Logger (AL): Records cryptographically chained entries into a tamper-evident audit ledger.
  • IPC Server (IPC1): Manages requests from the orchestrator for targeted scans or data retrieval.
    Key Responsibilities:
  • Initiates with elevated privileges, then drops them after initialization.
  • Delivers process and integrity data to the user-space orchestrator.
  • Appends all audit data exclusively to the write-only Audit Ledger.

daemoneye-agent --- Detection Orchestrator#

The DaemonEye Agent (daemoneye-agent) is the core coordinating service. It functions in user space with outbound-only network permissions, handling rule evaluation, alert generation, and data storage.
Core Modules:

  • Detection Engine (DE) --- Executes SQL-based detection rules over the local event database.
  • Alert Manager (AM) --- Deduplicates and manages alert lifecycles.
  • Rule Manager (RM) --- Loads, validates, and version-controls detection rules.
  • IPC Client (IPC2) --- Interfaces with the privileged collector via secure IPC.
  • Network Sinks (NS) --- Routes alerts to external systems such as SIEM, Syslog, or Webhooks.
    Responsibilities:
  • Requests raw data and hashes from procmond.
  • Executes detection logic and stores results in the Event Store.
  • Manages outbound alert distribution to configured destinations.

daemoneye-cli --- Operator Interface#

DaemonEye Command Line Interface tool (daemoneye-cli) is a command-line interface designed for analysts and operators to interact safely with the DaemonEye ecosystem.
Core Modules:

  • Query Executor (QE) --- Runs structured SQL queries through the orchestrator.
  • Health Checker (HC2) --- Evaluates component status and reports service health.
  • Data Manager (DM) --- Manages exports, imports, and data retention policies.
    Responsibilities:
  • Provides read-only access to query and inspect collected data.
  • Never interacts directly with privileged components.
  • Operates entirely through the orchestrator for safety and consistency.

daemoneye-lib --- Shared Core Library#

DaemonEye Shared Core Library (daemoneye-lib) provides a consistent foundation across all DaemonEye binaries.
It unifies serialization formats, cryptographic primitives, and configuration structures.
Modules:

  • Configuration (CFG) --- Hierarchical configuration loading and validation.
  • Models (MOD) --- Canonical data types for processes, detections, and alerts.
  • Storage (STO) --- Abstracts redb database operations.
  • Detection (DET) --- Provides SQL parsing and rule validation logic.
  • Alerting (ALT) --- Implements alert generation and sink definitions.
  • Crypto (CRY) --- Encapsulates hashing and signature utilities.

Data Stores#

DaemonEye maintains two persistent local data stores for isolation and verifiability:

  • Event Store (redb) --- Transactional database used by the orchestrator for event and rule data.
  • Audit Ledger (Certificate-Transparency-style) --- Append-only, cryptographically verifiable ledger written by procmond and other collectors based on collector-core framework.

External Systems#

All outbound communication is handled exclusively by the orchestrator's Network Sink subsystem.
Supported destinations include:

  • SIEM Systems --- e.g., Splunk, Elastic, or Kafka via connector modules.
  • Webhooks --- For lightweight alert forwarding or automation triggers.
  • Syslog --- Traditional system logging integration for legacy deployments.
    No component accepts inbound network connections, preserving the system's defensive posture.

Data Flow Summary#

  1. procmond collects process and hash data, forwarding it to the daemoneye-agent via IPC.
  2. The agent's Detection Engine executes rules and writes structured results to the Event Store.
  3. The Alert Manager generates alerts and dispatches them through configured Network Sinks.
  4. Operators use daemoneye-cli to query results, review alerts, and manage configurations.
  5. The Audit Logger continuously appends signed entries to the Audit Ledger for forensic verification.
    Result:
    This architecture enforces strict privilege separation, supports fully offline operation, and ensures end-to-end auditability of every action within DaemonEye---from process collection to alert delivery.

Component Responsibilities#

procmond (Privileged Process Collector)#

Primary Purpose: Minimal privileged component for secure process data collection with purpose-built simplicity.
Key Responsibilities:

  • Process Enumeration: Cross-platform process data collection using sysinfo crate
  • Executable Hashing: SHA-256 hash computation for integrity verification
  • Audit Logging: Certificate Transparency-style Merkle tree with inclusion proofs
  • IPC Communication: Simple protobuf-based communication with daemoneye-agent
    Security Boundaries:
  • Starts with minimal privileges, optionally requests enhanced access
  • Drops all elevated privileges immediately after initialization
  • No network access whatsoever
  • No SQL parsing or complex query logic
  • Write-only access to audit ledger
  • Simple protobuf IPC only (Unix sockets/named pipes)
    Key Interfaces:
#[async_trait]
pub trait ProcessCollector {
    async fn enumerate_processes(&self) -> Result<Vec<ProcessRecord>>;
    async fn handle_detection_task(&self, task: DetectionTask) -> Result<DetectionResult>;
    async fn serve_ipc(&self) -> Result<()>;
}

daemoneye-agent (Detection Orchestrator)#

Primary Purpose: User-space detection rule execution, alert management, and procmond lifecycle management.
Key Responsibilities:

  • Detection Engine: SQL-based rule execution with security validation
  • Alert Management: Alert generation, deduplication, and delivery
  • Rule Management: Rule loading, validation, and hot-reloading
  • Process Management: procmond lifecycle management (start, stop, restart, health monitoring)
  • Network Communication: Outbound-only connections for alert delivery
    Security Boundaries:
  • Operates in user space with minimal privileges
  • Manages redb event store (read/write access)
  • Translates complex SQL rules into simple protobuf tasks for procmond
  • Outbound-only network connections for alert delivery
  • Sandboxed rule execution with resource limits
  • IPC client for communication with procmond
    Key Interfaces:
#[async_trait]
pub trait DetectionEngine {
    async fn execute_rules(&self, scan_id: i64) -> Result<Vec<Alert>>;
    async fn validate_sql(&self, query: &str) -> Result<ValidationResult>;
}

#[async_trait]
pub trait AlertManager {
    async fn generate_alert(&self, detection: DetectionResult) -> Result<Alert>;
    async fn deliver_alert(&self, alert: &Alert) -> Result<DeliveryResult>;
}

daemoneye-cli (Operator Interface)#

Primary Purpose: Command-line interface for queries, management, and diagnostics.
Key Responsibilities:

  • Data Queries: Safe SQL query execution with parameterization
  • System Management: Configuration, rule management, health monitoring
  • Data Export: Multiple output formats (JSON, table, CSV)
  • Diagnostics: System health checks and troubleshooting
    Security Boundaries:
  • No network access
  • No direct database access (communicates through daemoneye-agent)
  • Input validation for all user-provided data
  • Safe SQL execution via daemoneye-agent with prepared statements
  • Communicates only with daemoneye-agent for all operations
    Key Interfaces:
#[async_trait]
pub trait QueryExecutor {
    async fn execute_query(&self, query: &str, params: &[Value]) -> Result<QueryResult>;
    async fn export_data(&self, format: ExportFormat, filter: &Filter) -> Result<ExportResult>;
}

daemoneye-lib (Shared Core)#

Primary Purpose: Common functionality shared across all components.
Key Modules:

  • config: Hierarchical configuration management
  • models: Core data structures and serialization
  • storage: Database abstractions and connection management
  • detection: SQL validation and rule execution framework
  • alerting: Multi-channel alert delivery system
  • crypto: Cryptographic functions for audit chains
  • telemetry: Observability and metrics collection

Data Flow Architecture#

The system implements a pipeline processing model with clear phases and strict component separation:

1. Collection Phase#

The daemoneye-agent sends a DetectionTask (ENUMERATE_PROCESSES) to procmond. Procmond enumerates processes from the system, computes hashes, writes to the audit ledger, and returns a DetectionResult with processes back to daemoneye-agent.

2. Detection Phase#

The Detection Engine loads detection rules from the Rule Manager, executes SQL queries against the Event Store, receives query results, generates alerts, and stores them back in the Event Store.

3. Alert Delivery Phase#

The Alert Manager delivers alerts in parallel to multiple sinks (Sink 1, Sink 2, Sink 3) and receives delivery results from each.

IPC Protocol Design#

Purpose: Secure, efficient communication between procmond and daemoneye-agent.
Protocol Specification:

syntax = "proto3";

// Simple detection tasks sent from daemoneye-agent to procmond
message DetectionTask {
    string task_id = 1;
    TaskType task_type = 2;
    optional ProcessFilter process_filter = 3;
    optional HashCheck hash_check = 4;
    optional string metadata = 5;
}

enum TaskType {
    ENUMERATE_PROCESSES = 0;
    CHECK_PROCESS_HASH = 1;
    MONITOR_PROCESS_TREE = 2;
    VERIFY_EXECUTABLE = 3;
}

// Results sent back from procmond to daemoneye-agent
message DetectionResult {
    string task_id = 1;
    bool success = 2;
    optional string error_message = 3;
    repeated ProcessRecord processes = 4;
    optional HashResult hash_result = 5;
}

Transport Layer:

  • Unix domain sockets on Linux/macOS
  • Named pipes on Windows
  • Async message handling with tokio
  • Connection authentication and encryption (optional)
  • Automatic reconnection with exponential backoff

Database Architecture#

Event Store (redb)#

  • Purpose: High-performance process data storage
  • Access: daemoneye-agent read/write, daemoneye-cli read-only
  • Features: WAL mode, concurrent access, embedded database
  • Schema: process_snapshots, scans, detection_rules, alerts

Audit Ledger (Certificate Transparency)#

  • Purpose: Tamper-evident audit trail using Certificate Transparency-style Merkle tree
  • Access: procmond write-only
  • Features: Merkle tree with BLAKE3 hashing and Ed25519 signatures
  • Implementation: rs-merkle for inclusion proofs and periodic checkpoints

Security Architecture#

Privilege Separation#

  • Only procmond runs with elevated privileges when necessary
  • Immediate privilege drop after initialization
  • Detection and alerting run in user space
  • Component-specific database access patterns

SQL Injection Prevention#

  • AST validation using sqlparser crate
  • Prepared statements and parameterized queries only
  • Sandboxed detection rule execution with resource limits
  • Query whitelist preventing data modification operations

Resource Management#

  • Bounded channels with configurable backpressure policies
  • Memory budgets with cooperative yielding
  • Timeout enforcement and cancellation support
  • Circuit breakers for external dependencies

Performance Characteristics#

Process Collection#

  • Baseline: <5 seconds for 10,000+ processes
  • CPU Usage: <5% sustained during continuous monitoring
  • Memory Usage: <100MB resident under normal operation
  • Hash Computation: SHA-256 for all accessible executables

Detection Engine#

  • Rule Execution: <100ms per detection rule
  • SQL Validation: AST parsing and validation
  • Resource Limits: 30-second timeout, memory limits
  • Concurrent Execution: Parallel rule processing

Alert Delivery#

  • Multi-Channel: Parallel delivery to multiple sinks
  • Reliability: Circuit breakers and retry logic
  • Performance: Non-blocking delivery with backpressure
  • Monitoring: Delivery success rates and latency metrics

Cross-Platform Strategy#

Process Enumeration#

  • Phase 1: sysinfo crate for unified cross-platform baseline
  • Phase 2: Platform-specific enhancements (eBPF, ETW, EndpointSecurity)
  • Fallback: Graceful degradation when enhanced features unavailable

Privilege Management#

  • Linux: CAP_SYS_PTRACE, immediate capability dropping
  • Windows: SeDebugPrivilege, token restriction after init
  • macOS: Minimal entitlements, sandbox compatibility

Component Communication#

procmond <-> daemoneye-agent#

  • Protocol: Custom Protobuf over Unix Sockets/Named Pipes
  • Direction: Bidirectional with simple task/result pattern
  • Security: Process isolation, no network access

daemoneye-agent <-> daemoneye-cli#

  • Protocol: Local IPC or direct database access
  • Direction: daemoneye-cli queries daemoneye-agent
  • Security: Local communication only, input validation

External Communication#

  • Alert Delivery: Outbound-only network connections
  • SIEM Integration: HTTPS, mTLS, webhook protocols
  • Security Center: mTLS with certificate authentication

Error Handling Strategy#

Graceful Degradation#

  • Continue operation when individual components fail
  • Fallback mechanisms for enhanced features
  • Circuit breakers for external dependencies
  • Comprehensive error logging and monitoring

Recovery Patterns#

  • Automatic retry with exponential backoff
  • Health checks and component restart
  • Data consistency verification
  • Audit trail integrity validation
    This architecture provides a robust foundation for implementing DaemonEye's core monitoring functionality while maintaining security, performance, and reliability requirements across all supported platforms.