Changes between Initial Version and Version 1 of Security considerations

Timestamp:

04/30/25 10:03:09 (3 weeks ago)

Author:

enno

Comment:

--

Security considerations

@@ +1 @@
+Let’s go through this from a security architecture perspective, and identify:
+
+Potential risks
+
+Mitigation strategies
+
+Recommendations specific to Guix in air-gapped, classified use
+
+🛡️ Security Risks in an Air-Gapped Guix Workflow
+1. Supply Chain Attacks via Source Code
+Even though you're building from source, the upstream source code (tarballs, Git repos) may be maliciously modified.
+
+Guix uses cryptographic hash verification, but only against what is declared in the Guix package definition — not against independent trust anchors.
+
+✅ Mitigations:
+
+Use guix build --source with hash-locked package definitions (content-addressed derivations).
+
+Use reproducible builds and determinism checks (e.g., compare build outputs across trusted builders).
+
+Consider maintaining a private mirror of trusted source code, and pin hash checks yourself.
+
+Use content scanning tools (e.g., static analyzers) on all .tar.gz and Git checkouts.
+
+2. Compromise via Channel Updates
+Your Guix package definitions come from Git channels (e.g., guix.git, or your own).
+
+If your channel is compromised, malicious package definitions could be delivered.
+
+✅ Mitigations:
+
+Use a pinned commit hash in your channels.scm.
+
+Verify the channel commit with signed Git commits or tags (Guix supports this).
+
+Host your own internal Guix channel for critical environments — control what definitions are trusted.
+
+Use guix time-machine to avoid rolling updates.
+
+3. Media Transfer Risks (USB, SD cards)
+USB drives used for transferring .nar files or source archives can be a vector for malware, even in an air-gapped setup.
+
+✅ Mitigations:
+
+Always format and scan USB media on a controlled, known-clean staging machine before inserting into classified systems.
+
+Use write-once optical media (DVD-R) where appropriate for immutable transfer.
+
+Prefer hash verification of transferred files (sha256sum sources.nar) using offline-known-good hashes.
+
+4. Build Environment Leakage
+If the build process writes temporary files or outputs data to places outside the Guix store, secrets or traces of sensitive data could leak or persist.
+
+✅ Mitigations:
+
+Use guix build inside a dedicated, minimal, reproducible system (e.g., a guix system vm).
+
+Enable build sandboxing (enabled by default in Guix).
+
+Disable networking in builders if not already (Guix does this by default, but confirm your configuration).
+
+Consider full-disk encryption for the build system.
+
+5. Tampered Nar Archives
+.nar archives imported into your air-gapped server could be tampered with in transit.
+
+✅ Mitigations:
+
+Sign the archive on the export side and verify the signature on the import side.
+
+Use GPG or minisign for signing hashes.
+
+Maintain a hash whitelist of approved .nar files on the classified system.
+
+Store all .nar imports in a sealed append-only log for auditing.
+
+✅ High-Security Recommendations for Guix in Classified Environments
+
+Concern Recommendation
+Source authenticity     Use fixed-output derivations with pinned hashes
+Package definition trust        Host internal Guix channel; pin commit hashes
+Archive integrity       Sign .nar files and verify signatures
+Reproducibility Use multiple offline builders to cross-check outputs
+Logging Keep an audit trail of all imports and builds
+Isolation       Build in virtual machines or system containers with no network
+Transfer media  Sanitize USBs or use write-once optical media
+User separation Separate users for import, build, audit, and deployment tasks
+🔐 Final Thoughts
+Guix offers an excellent foundation for secure, reproducible software environments.
+
+But air-gapped security is about the whole process, not just the tooling.
+
+You should treat the Guix channel, source transport, build environment, and auditability as a single trusted pipeline.