Merged
Conversation
Collaborator
|
@juliuskoskela very nice. |
Contributor
There was a problem hiding this comment.
Pull Request Overview
This pull request implements Forward Secure Sealing (FSS) for systemd journal logs to provide cryptographic tamper-evidence for audit logs in the Ghaf framework. FSS uses HMAC-based sealing chains to detect any tampering with journal files.
Key changes:
- Adds a new
fss.nixmodule that configures FSS key generation and periodic journal verification - Enables libgcrypt in systemd (required for FSS support)
- Configures
Seal=yesin journald when FSS is enabled for both client and server logging
Reviewed Changes
Copilot reviewed 5 out of 5 changed files in this pull request and generated 2 comments.
Show a summary per file
| File | Description |
|---|---|
| modules/common/systemd/base.nix | Enables libgcrypt support in systemd package (required for FSS) |
| modules/common/logging/fss.nix | New module implementing FSS key setup, verification services, and audit monitoring |
| modules/common/logging/default.nix | Imports the new FSS module |
| modules/common/logging/client.nix | Enables journal sealing when FSS is enabled |
| modules/common/logging/server.nix | Enables journal sealing when FSS is enabled |
|
There are some failures in the pre-merge tests for laptops
|
f72e371 to
af81d3f
Compare
79afb89 to
58538be
Compare
58538be to
6e08792
Compare
Collaborator
|
looks like you merged and not rebased. |
2dbeb8c to
1184b7c
Compare
Contributor
everton-dematos
left a comment
There was a problem hiding this comment.
Can you squash the commits? Maybe into 1 or 2... you choose how many 😃
1184b7c to
2603104
Compare
2603104 to
db87fad
Compare
everton-dematos
approved these changes
Dec 17, 2025
db87fad to
4d30d47
Compare
4d30d47 to
4ba5048
Compare
Implement Forward Secure Sealing (FSS) for systemd journal logs to provide cryptographic tamper-evidence for audit logs. FSS uses HMAC-SHA256 chains to seal journal entries at regular intervals, making any tampering detectable. Key features: - Per-component FSS key pairs (host and each VM have independent keys) - Automatic key generation on first boot via journal-fss-setup service - Periodic integrity verification via journal-fss-verify timer (hourly) - Verification on boot to detect tampering during offline periods - Audit rules to monitor FSS key and journal access - Integration with existing logging infrastructure Changes: - Add FSS module (modules/common/logging/fss.nix) with setup/verify services - Propagate logging.enable to all VMs for consistent FSS support - Enable audit subsystem when FSS is enabled (provides auditctl) - Add fss-test diagnostic tool to debug images - Add FSS test suite for CI validation - Add ADR and user documentation for FSS The FSS implementation ensures that any modification to sealed journal entries breaks the HMAC chain and is detected during verification, providing strong tamper-evidence for security-critical audit logs. Signed-off-by: Julius Koskela <julius.koskela@unikie.com>
This comment was marked as outdated.
This comment was marked as outdated.
Improve journal FSS verification to handle user journal failures separately from system journal failures. User journals may fail verification due to entries written before FSS initialization, which is expected and does not indicate tampering. Also propagate the listener configuration to VM modules and add missing mock option for tests. Signed-off-by: Julius Koskela <julius.koskela@unikie.com>
Per systemd documentation, journalctl --rotate is required after --setup-keys to create a new journal file that uses the FSS keys. Without rotation, entries in the existing journal remain unsealed. Changes: - Add journalctl --rotate after FSS key generation - Update test script to use verification key for sealed journals - Simplify service dependencies (no socket ordering needed) Signed-off-by: Julius Koskela <julius.koskela@unikie.com>
The FSS test script used $(hostname) to locate verification keys and sentinel files. On net-vm, the dynamic hostname service overwrites the hostname for AD integration, causing a mismatch with the Nix build-time path used by journal-fss-setup. Write an fss-config pointer file from the setup script into /var/log/journal/<machine-id>/fss-config containing the Nix-configured key directory path. The test script reads this pointer first and falls back to hostname-based discovery for backward compatibility. Also separate user journal failures from system journal failures in the test script, treating user journal verification failures as warnings since they contain pre-FSS entries. Signed-off-by: Julius Koskela <julius.koskela@unikie.com>
…detection
Remove ConditionPathExists guard from setup service so it can re-run on
boot to write fss-config on existing deployments where the file was never
created. Add one-time journal rotation after FSS key setup to move
pre-FSS entries to archive, fixing EBADMSG ("Bad message") during
verification. Add systemctl cat fallback to test 6 for timer detection
in microVMs where list-unit-files may not show the timer.
Signed-off-by: Julius Koskela <julius.koskela@unikie.com>
|
|
brianmcgillion
approved these changes
Feb 3, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description of Changes
Implements Phase 1 – Forward Secure Sealing (FSS) for the Ghaf logging subsystem, establishing cryptographic tamper-evidence and audit-log integrity for all systemd journal entries.
This phase provides the foundation for verifiable audit trails by enabling and managing systemd’s built-in Forward Secure Sealing mechanism.
Key Additions
modules/common/logging/fss.nixNew
ghaf.logging.fssoption set (enable,keyPath,sealInterval,verifyOnBoot,verifySchedule).Adds hardened systemd units:
journal-fss-setup.service– Generates FSS keys on first boot, extracts and stores the verification key under/persist/common/journal-fss.journal-fss-verify.service+ timer – Performs periodic and boot-time integrity verification, reporting via journald (AUDIT_LOG_VERIFY_COMPLETED/AUDIT_LOG_INTEGRITY_FAIL).Integrates tmpfiles + auditd rules to monitor FSS key paths and sealed journals.
logging/client.nix/logging/server.nixSeal=yesin journald configuration when FSS is active.logging/default.nixsystemd/base.nixwithGcryptto ensure systemd is built with libgcrypt support (required for FSS HMAC chains).Highlights
Type of Change
Related Issues / Tickets
Implements Phase 1 of the Audit Log Integrity and Sealing roadmap.
Forms the baseline for Phase 2, which will introduce:
Checklist
ghaf-docs/logging)make-checkspasses locallyTesting Instructions
Applicable Targets
x86_64x86_64aarch64(pending validation)Installation Method
nixos-rebuild switchTest Steps to Verify
Enable FSS in configuration:
Rebuild system:
Reboot and confirm setup service:
Verify sealing active:
Expected:
No errors found.Check periodic verification timer:
systemctl list-timers | grep journal-fss-verifyInspect audit events:
Next Phase (Planned): Integrate TPM 2.0 for hardware-rooted key sealing and CA-signed attestation of verification keys to enable cryptographically provable audit integrity across trusted nodes.