System Logs

Ghaf’s logging pipeline for journald and auditd: centralized aggregation, retention, and encryption to protect log confidentiality and tamper-evidence across isolation boundaries.

Logging Architecture

This section documents the current logging architecture of the Ghaf Framework and summarizes the logging-related modules deployed across the System VMs and Application VMs (Figure 1).

The topology in Figure 1 is organized around two VM classes: System VMs and Application VMs. Each VM produces system and security events locally via systemd-journald, including auditd entries routed into the journal. Non-admin VMs then forward their journal stream to the Admin VM for aggregation. From there, the Admin VM forwards a unified stream to a remote backend, enabling centralized monitoring and analysis without requiring direct network exposure of every VM. In the Figure 1, purple blocks denote components that produce or hold logs (e.g., Auditd and Journal logs), while blue blocks denote modules that enforce security properties on the logging pipeline (e.g., integrity protection, encryption, and retention).

Log producers and local collection

The purple blocks in Figure 1 represent the log sources in Ghaf Platform: (i) systemd-journald (the system journal) and (ii) auditd (the Linux auditing subsystem). Together, they form the per-VM record of operational activity and security-relevant events.

On every VM, system services, kernel messages, and application/service outputs are collected by systemd-journald as the default local logging facility. In parallel, auditd captures security audit events based on the configured rule set. These audit events are then forwarded into systemd-journald, so that both system logs and audit logs are available through a single local journal stream. This keeps the logging surface consistent across VM types (i.e., Application VMs and System VMs) and provides one standardized interface for local persistence and subsequent forwarding.

Audit policy and rule coverage

Audit collection is guided by a layered rule approach. Per-VM audit rules include (i) Nix-specific rules (to capture Ghaf/NixOS operational activity and configuration changes), (ii) STIG-aligned rules for compliance-oriented auditing, (iii) OSPP-aligned rules for security auditing baselines, and (iv) VM-specific rules to tailor monitoring to each VM’s role. The Ghaf Host additionally includes extra host rules (as shown in the host audit-rule block), reflecting that the host has unique responsibilities and a distinct attack surface compared to guest VMs.

Intra-platform log forwarding

All non-admin VMs (including both system and application VMs) forward their journald streams to the Admin VM. The Admin VM plays a dual role: it (i) generates its own logs locally (like any other VM) and (ii) runs a listener/receiver that ingests forwarded logs from the other VMs. This makes the Admin VM the single aggregation point inside the Ghaf Platform, reducing the need for each VM to maintain independent connectivity to remote logging infrastructure and allowing policy enforcement to be concentrated in one place.

Once logs are aggregated, the Admin VM forwards the unified journal stream to the Remote Log Server. In the Figure 1, the remote server is depicted as an external storage/service endpoint, and the link represents the log shipping path from the platform boundary to the remote backend. This remote endpoint is intended to support centralized querying, alerting, and longer-term storage beyond what is retained locally.

Secure Logging

The blue blocks in Figure 1 represent the security controls applied to the logging pipeline (i.e., mechanisms that protect logs as they are stored, forwarded, and retained across isolation boundaries). Ghaf’s design emphasizes three complementary properties: integrity/tamper-evidence, retention, and confidentiality (in transit and at rest).

Integrity (Log Integrity / FSS sealing proxy): The Figure 1 highlights a log integrity module based on an FSS sealing proxy, which is intended to provide tamper-evidence for logs. Conceptually, this strengthens assurances that once logs are generated and recorded, unauthorized modification can be detected during later inspection or after shipping to remote storage.
Retention (Journal and Audit): Retention policies are treated as a first-class concern and are applied in a tiered manner: (i) per-VM retention for local journal/audit logs, (ii) retention at the Admin VM for aggregated logs, and (iii) retention at the remote backend for long-term storage. Explicit retention boundaries help balance forensic usefulness with storage constraints and reduce exposure from over-retaining sensitive telemetry.
Confidentiality at rest (Log security / Data-at-rest encryption): Local journal and audit storage can be protected via data-at-rest encryption, limiting the impact of offline access or storage-layer compromise.
Confidentiality in transit (Encrypt logs in transit): The Figure 1 calls out encryption in transit, both for the VMs → Admin VM, and for Admin VM → Remote Log Server paths. This protects logs while traversing untrusted networks and prevents passive observation or trivial manipulation between the platform boundary and the remote backend. The following Section gives more details on the encryption of logs on the Ghaf Platform.

Encryption in Transit and at Rest

Why encrypt logs

Logs are sensitive by design. They routinely contain process IDs, usernames, device identifiers, configuration snapshots, kernel error messages, and occasionally secrets from misconfigured software. Exposing these provides reconnaissance value and can aid privilege escalation.
Ghaf separates functionality across MicroVMs and hardened domains. Log streams frequently cross trust boundaries (for example, from an AppVM to a SysVM or host). Anything that crosses a boundary must assume a hostile transport.
Logs are part of the forensic record. Ensuring they cannot be read or altered by an adversary is essential for reliable incident response and compliance.

Encryption in transit

Implemented with TLS/SSL-protected channels (for example, HTTPS endpoints, syslog over TLS, gRPC with mTLS, or SSH tunnels) between hosts and MicroVMs.
Protects confidentiality when logs traverse networks, virtual busses, or shared host paths between VMs.
Prevents tampering and spoofing by authenticating endpoints and enabling integrity checks, so attackers cannot inject or modify events in flight.
Aligns with Ghaf’s compartmentalization model (modules/microvm/*) and least-privilege service design: even if an intermediate domain is compromised, encrypted channels limit what can be observed or altered.

Encryption at rest

Implemented with whole‑disk encryption (for example, LUKS/dm‑crypt) on host and VM images; logs under /var/log are written to encrypted volumes by default. For exported archives, store them on encrypted partitions or object storage with server‑side encryption.
Defends against offline access: if a device, VM image, or storage medium is stolen or inspected, encrypted log files remain unreadable without keys.
Limits blast radius of host or service compromises by requiring access to both storage and keys.
Preserves evidentiary integrity: cryptographic protections and immutability controls make post‑incident analysis trustworthy.
Complements kernel/host hardening profiles (see modules/common/profiles/kernel-hardening.nix) and auditing (modules/common/security/audit/*), which increase the value and sensitivity of what is logged.

Threats mitigated

Eavesdropping on inter‑VM communications or host paths used to collect/forward logs.
On‑path modification or injection of events to hide activity or create false trails.
Data harvesting from powered‑off devices, snapshots, or backups.
Abuse of excess privileges by non‑logging components that can access raw transport or storage.

Operational benefits

Compliance alignment with common security baselines that require protecting security telemetry at rest and in transit.
Higher signal quality for detection and faster, more confident incident response.
Consistent behavior across environments thanks to declarative, reproducible configuration (Nix‑based builds) and hardened systemd/AppArmor service sandboxes.