Linux test plan

What to test on a Linux release so the baseline still holds: the checks of Red Hat Enterprise Linux 10 V1R3, by area

Derive from STIG Include CAT III Owner's templates

The release under test Version Hardware

Areas to test Hardware root of trust and secure enclave 6 Platform SSO and identity 1 Authentication 104 Disk encryption 27 MDM enrolment 3 Updates and release changes 3 Network 56 Logging and audit 92 Everything else 153 Untick an area to leave it out of the exports; it stays on the page, marked as not tested this time.

Export the kept checks Report look Untick a check, then Rebuild or export; the form carries the state and nothing is stored. One area is drawn at a time; what you untick in one is kept when you open another, and every export covers the whole plan: the checks kept, what was left out and why, a findings table and a sign-off.

The report looks

Plain: Calibri and grey tables, nothing else: the look before styles.
Formal assessment: A government assessment report in the SP 800-53A manner: serif headings, numbered sections, cover page. Cover page. Numbered sections.
Engineering runbook: For the engineer at the keyboard: monospaced headings, dark command blocks. Numbered sections.
Executive: Navy and teal with a cover page: for the people who sign it off. Cover page.
Compact checklist: Black on white, small type, no cover: prints the most checks per page.
Modern: A clean product look in indigo and slate.
Dark console: Light text on a dark page, terminal colours: for screens, not paper.
Board: Issue-tracker blues and lane greys, as the decisions board draws them.
Audit workpaper: Ledger green and auditor blue, with room for initials and references. Cover page. Numbered sections.
Markdown-native: How the report reads on GitHub: system fonts, ruled headings, grey code.
Word: Office's own blues: the house style of a document written in Word. Cover page. Numbered sections.

The look applies to Word, PDF, LaTeX and the printable checklist; Markdown, CSV and JSON stay plain. Each follows one of the mockups in docs/mockups/exports.

Link to this plan: the release, hardware and areas as a URL to bookmark or send; unticked checks do not travel with it.

Hardware root of trust and secure enclave 6 kept

owner's template Run mokutil --sb-state.
Ubuntu security documentation, "UEFI Secure Boot" (Secure Boot, TPM, disk encryption and FIPS mode on a Linux host)
Success looks like: SecureBoot enabled.
If it does not: Disabled means firmware lets unsigned kernels boot; enable Secure Boot in firmware and confirm the distribution's shim is enrolled (a host with third-party kernel modules needs its MOK key enrolled first).
owner's template Run ls /sys/class/tpm and tpm2_getcap properties-fixed.
Red Hat, "Encrypting block devices using LUKS" (Security hardening, RHEL 9) (Secure Boot, TPM, disk encryption and FIPS mode on a Linux host)
Success looks like: tpm0 exists and the family indicator is 2.0; the manufacturer and firmware version go into the inventory.
If it does not: No tpm0 means the TPM is off in firmware or the host is a VM without a vTPM; LUKS keys and measured boot then have nothing to bind to, so record the exception against the STIG.
owner's template Run lsblk and cryptsetup status on each mapped volume, then cryptsetup luksDump on the device.
Red Hat, "Encrypting block devices using LUKS" (Security hardening, RHEL 9) (Secure Boot, TPM, disk encryption and FIPS mode on a Linux host)
Success looks like: Every local data partition is TYPE crypt; the header is LUKS2 with aes-xts-plain64 and a 512-bit key.
If it does not: An unencrypted local partition fails RHEL-09-231190; it cannot be encrypted in place, so rebuild from the fleet's image with encryption at install.
owner's template On RHEL, run fips-mode-setup --check; on Ubuntu Pro, run pro status and cat /proc/sys/crypto/fips_enabled.
Red Hat, "Switching RHEL to FIPS mode" (Security hardening, RHEL 9) (Secure Boot, TPM, disk encryption and FIPS mode on a Linux host)
Success looks like: RHEL reports FIPS mode is enabled; Ubuntu reports fips-updates (or fips) enabled and the kernel flag reads 1.
If it does not: FIPS mode cannot be turned on cleanly after installation on RHEL (install with fips=1 and rebuild) and is irreversible on Ubuntu; a FIPS host on RHEL 10 has no active certificate yet (the modules are under test), so a certificate-backed requirement stays on RHEL 9.
owner's template Run the STIG profile scan with OpenSCAP, oscap xccdf eval --profile xccdf_org.ssgproject.content_profile_stig --results results.xml --report report.html /usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xml (the matching data stream on RHEL 10 or Ubuntu's usg), and open the report.
Red Hat, "Scanning the system for configuration compliance and vulnerabilities" (Security hardening, RHEL 9) (Secure Boot, TPM, disk encryption and FIPS mode on a Linux host)
Success looks like: Every rule the baseline applies is pass; notchecked rules are the manual ones this plan covers; notapplicable rules match the host's role.
If it does not: A fail names the rule and the STIG id; fix with the STIG's own procedure (or oscap xccdf generate fix for a script to review first), then re-scan. Never run --remediate on a host in service without a rollback.
owner's template Where the host signs users in with Entra ID (Ubuntu's authd with the Microsoft Entra ID broker, or RHEL's SSSD generic identity provider), run getent passwd <user>@<tenant domain> and ssh -l <user>@<tenant domain> localhost.
Red Hat, "Configuring SSSD to use a generic identity provider" (RHEL 10) (Secure Boot, TPM, disk encryption and FIPS mode on a Linux host)
Success looks like: The user resolves and signs in through the device-code or browser flow with MFA; a disabled Entra user is refused within the cache lifetime.
If it does not: A user who still signs in after being disabled in Entra is a cached credential; shorten the offline cache or make the host online-only. RHEL's provider is a Technology Preview; a production host uses Entra Domain Services with the AD backend instead.

Any release

Choose a version and hardware above and the plan leaves out what does not apply to them, saying why. Every release and the hardware it runs on is on the Fleet page.

Derived from

STIG: Red Hat Enterprise Linux 10 V1R3
Checks: 445 tested: 430 from the publishers' procedures, 15 from the owner's templates
By area: Hardware root of trust and secure enclave 6, Platform SSO and identity 1, Authentication 104, Disk encryption 27, MDM enrolment 3, Updates and release changes 3, Network 56, Logging and audit 92, Everything else 153

Templates 4

Conditional Access holds on the new release 3 steps · Authentication · conditional-access.yaml
Whatever the platform, the new OS release must still satisfy the compliance and device-state signals the Conditional Access policies ask for.
Secure Boot, TPM, disk encryption and FIPS mode on a Linux host 6 steps · Hardware root of trust and secure enclave · hardware-root-linux.yaml
Red Hat Enterprise Linux 9 and 10 and Ubuntu 22.04 and 24.04 LTS. Run as root on a host built from the fleet's image after the STIG profile is applied.
LUKS encryption on every data volume, with a header backup kept off the host 3 steps · Disk encryption · luks-escrow.yaml
The STIG requires encrypted storage for data at rest; this template tests the install-time encryption and the recovery material on the new release.
Automated enrolment and the baseline profiles on a wiped device 3 steps · MDM enrolment · mdm-enrolment.yaml
The first thing to test on a new release is that a wiped device enrols without a hand on it and receives the baseline.

Templates are YAML files under data/test-plans in the repository; the owner extends them by adding a file. Each says which releases and hardware it applies to, what success looks like and what to do when a step fails, and cites the document it follows. They are labelled as the owner's, not the publisher's.

How the areas are chosen

Each check is filed by the words in its title (then its procedure): Secure Enclave, TPM, secure boot and attestation under the hardware root of trust; Platform SSO, Entra, Kerberos and passkeys under SSO; BitLocker, FileVault and LUKS under disk encryption; passwords, smart cards, session lock and sudo under authentication; audit and logs under logging; firewall, SMB, SSH, TLS, Bluetooth and sharing under network; updates and releases under updates; enrolment and management under MDM; browsers by name; meeting rooms under collaboration. The rest is "everything else". The words are the publishers'; only the filing is this product's.

The Linux baseline · Fleet · All baselines