PCI-DSS v4 hardening Salt formulas for SUSE, generated by scap2salt and packaged as MLM/Uyuni formulas with form. Two per-OS RPMs are attached — assign one per system-group.
Coverage (pci-dss-4 profile)
| SLE 15 (AppArmor) | SLE 16 (SELinux) | |
|---|---|---|
| Native mapping | 209/238 remediable (87%) | 197/230 (85%) |
| Live OpenSCAP compliance | 92.9% (223/17) | 91.6% (207/19) |
What's new in 1.0.14
service_*_disablednow passes — the OVAL requiresLoadState=masked, not just disabled. Disabled-service rules now alsoservice.masked(e.g.service_nftables_disabled→ pass).- Formula RPM now deploys into the live MLM container volumes on SL Micro. The Uyuni Salt master reads
/srv/salt+/srv/formula_metadata, which on a containerised server are podman volumes under/var/lib/containers/storage. Because SL Micro installs RPMs viatransactional-update(whose%postruns in a chroot where that storage is shadowed), deployment is now done on first boot by a bundleddeploy-<formula>.serviceoneshot (vendor-enabled via a packagedmulti-user.target.wantssymlink), with a/usr/libexec/deploy-<formula>.shhelper for immediate deploy. - Per-OS formula names
PCI_DSS_v4_SLE15/PCI_DSS_v4_SLE16for clean, case-correct labels in the MLM Formulas list. - Looked into and documented the residual fails:
sysctl_fs_suid_dumpable(runtime hardened to 0; static check left untouched to avoid anrpm_verify_hashesviolation) and the pam-file hashing rules (oscap 1.4.1 can't credit them on SUSE; the effective controlset_password_hashing_algorithm_logindefspasses).
Install (containerised MLM on SL Micro)
sudo transactional-update pkg install --allow-unsigned-rpm ./PCI_DSS_v4_SLE16-hardening-formula-1.0.14-0.noarch.rpm
sudo reboot # required to activate the transactional install; the formula auto-deploys on bootThen assign PCI DSS V4 SLE16 (or …SLE15) to a system/group in the Formulas tab, toggle categories, and apply the highstate. See each RPM's bundled README for the writable-root and traditional-server paths.