Handbook sections▾
Foundations
Understanding the threats to a Linux hostWhy we hardenThe defense principles behind every ruleEffective configuration: the truth no file holdsThe standards Pavois maps toSOCLE control ID modelEvidence & exportsHow the A-E grade is computedWhat a PASS proves: the qualified verdictTrust model for the evidence bundleIs SOCLE just your own norm? (governance & the circularity question)What Pavois covers, and what it doesn'tDomains
Hardening SSHHardening PAMMandatory Access Control (SELinux / AppArmor)Hardening the host firewallHardening sudoFile Permissions & OwnershipMount & filesystem hardeningHardening kernel modulesHardening the kernel & network with sysctlAudit logging with auditdHardening logging with journald and rsyslogHardening systemd servicesPackage hygieneHardening the bootloader (GRUB)Synchronizing timeLogin banners and MOTDControlling cron and at accessHardening the GNOME desktop (dconf)Tooling
Undo a hardening run: restore pointsOperating Pavois: privileges, air-gap, timing, exceptionsRun Pavois in CI (GitHub Actions)Feature status: delivered, partial, roadmapGovernance: licence, versioning, provenance, securityTrust model for the evidence bundle
Last reviewed
A bundle is tamper-evident on its own; it becomes opposable audit evidence only once signed under a trust policy your organization accepts. Who signs, with which identity, how keys rotate, and how to verify offline.
Two states, one bundle
pavois bundle produces a directory whose manifest.json records every artifact's SHA-256, the tool and ruleset versions, the pavois binary digest, the target and the grade delta. The manifest's own digest is the single value you sign. That gives a bundle two distinct states, and the distinction is the whole point:
- Tamper-evident (unsigned).
pavois bundle verify <dir>recomputes every checksum and the manifest digest. Any byte changed after packaging is caught. This proves internal consistency: nobody edited a report after the fact. It does not prove who produced it: an attacker who regenerates the whole bundle also regenerates a consistent manifest. - Signed audit evidence. You sign the manifest digest with an identity, and
pavois bundle verify <dir> --require-signaturefails unless a valid signature is present. Now the bundle is bound to a signer your auditor can name. This, and only this, is what we call opposable.
pavois never owns a signing key. It computes and verifies; the trust anchor is your identity, on purpose, so the evidence is yours, not the tool's.
Choosing how to sign
| Method | Trust anchor | Use when |
|---|---|---|
| Hash only (no signature) | none, integrity only | internal iteration, CI artifacts you don't publish |
| GPG detached signature | a public key you distribute | you already run a GPG/PKI workflow |
| cosign keyed | a key in a file or KMS (AWS/GCP/Azure) | an org key, rotated and access-controlled |
| cosign keyless (OIDC) | a short-lived cert tied to an OIDC identity, logged in Rekor | CI signing without long-lived keys |
For a CI-built release, keyless OIDC (the same mechanism the release pipeline uses for its own SLSA build-provenance attestation) is the lowest-maintenance: there is no key to leak, and the transparency log records when and by whom each signature was made. For a human signing a quarterly audit package, an org KMS key or GPG is usually simpler to explain to an auditor.
Identity, rotation, revocation
A signature is only as good as the policy that says which identity is acceptable. Decide and write down:
- Accepted identity. The exact KMS key ARN, GPG fingerprint, or OIDC identity + issuer (
--certificate-identity,--certificate-oidc-issuerwith cosign) that your auditor will check against. A signature from any other identity must fail your policy, not just passverify. - Rotation. Keys rotate on a schedule (see NIST SP 800-57). Record the validity window per key so an old bundle stays verifiable against the key that was current when it was signed.
- Revocation. If a key is compromised, publish the revocation and re-sign the still-valid bundles. Keyless signing sidesteps long-lived key revocation because certs are short-lived by design.
Verifying offline
Verification must work without calling home, because an auditor often runs it in an isolated environment:
pavois bundle verify evidence/ --require-signature
# re-checks every artifact SHA-256, the manifest digest, and the signatureThe checksums and manifest are self-contained. For a GPG signature, import the public key once; for cosign keyed, supply the public key; for cosign keyless, the certificate and Rekor inclusion proof travel with the bundle so the chain can be checked against a pinned root rather than a live service. Keep the public verification material (public key, cert, root) alongside your retention copy.
Retention
An audit package is only useful if it survives the audit window. Store the bundle, its signature and the public verification material together, immutably (object-lock or WORM storage), for at least your compliance retention period. The pavois binary digest in the manifest lets you later prove which exact build produced the evidence, even after the tool has moved on.