postprocess: Disable empty password authentication via authselect#1934
postprocess: Disable empty password authentication via authselect#1934sebrandon1 wants to merge 1 commit into
Conversation
Activate authselect with the 'without-nullok' feature to remove the nullok parameter from pam_unix.so in system-auth and password-auth. This prevents authentication with empty passwords on RHCOS nodes. Uses the supported RHEL mechanism (authselect) rather than replacing PAM files directly. The without-nullok feature was purpose-built for this use case by the authselect maintainer in 2018: authselect/authselect@e1fbbdc RHCOS nodes are managed infrastructure with no legitimate use case for empty password authentication. Flagged as HIGH severity across all compliance profiles (E8, CIS, Moderate, PCI-DSS). Related: - authselect issue: authselect/authselect#94 - Upstream scanner fix: ComplianceAsCode/content#14602
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: sebrandon1 The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
|
@sebrandon1: The following tests failed, say
Full PR test history. Your PR dashboard. DetailsInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here. |
|
I think this is reasonable but it should likely be done in the base layer (https://github.com/coreos/rhel-coreos-config) or maybe even in Fedora CoreOS directly (https://github.com/coreos/fedora-coreos-config). |
|
Note that while I agree that this is a valid hardening option, users must explicitly set an empty password for the root account for that option to actually matter as we do not set a password for root by default. |
|
@travier Noted! I'll try https://github.com/coreos/rhel-coreos-config next. Thank you! |
|
Moved to coreos/rhel-coreos-config#255 per @travier's feedback to target the base layer instead. |
H2 (PAM Empty Passwords) had upstream_verdict "upstream-pr-exists" but openshift/os#1934 was closed. Changed to "upstream-candidate". Updated meta audit note to reflect actual counts: 0 upstream-pr-exists, 11 upstream-candidate, 14 ran-only.
openshift/os#1934 was closed — maintainer directed OS-level changes to the base layer (coreos/rhel-coreos-config). Updated H2 upstream entry to reference coreos/rhel-coreos-config PR #255 (open, awaiting ok-to-test).
Add pr_history array to upstream entries in tracking.json to record every PR attempt with its outcome and reason: - H2: openshift/os#1934 (closed, redirected to base layer), coreos/rhel-coreos-config#255 (open), ComplianceAsCode/content#14602 (open) - L2/M2: coreos/rhel-coreos-config#264 (closed, redirected to RHEL level) Schema: pr_history[].{repo, pr, url, state, opened, closed, outcome, reason} Render PR History table on group detail pages showing state badges and closure reasons for each upstream attempt.
2 participants
RHCOS inherits
nullokin PAM from the RHEL defaults, which permits authentication with empty passwords. RHCOS nodes are managed infrastructure with no legitimate use case for password-based login, let alone empty passwords, so this has no functional impact on existing deployments.This adds a postprocess step that runs:
and verifies that
nullokwas removed fromsystem-authandpassword-auth.Why this change
This is flagged as a HIGH severity finding across every compliance profile that applies to RHCOS: Essential 8, CIS, NIST Moderate, and PCI-DSS. Unlike many hardening recommendations where benchmarks disagree, removing
nullokis consistent across all of them.Today, the compliance-operator remediation for this finding is broken on RHCOS 9 — it generates RHEL 8 era PAM templates that don't apply cleanly. Fixing it at the image level eliminates the issue for all clusters without requiring per-node MachineConfig remediation.
Why the maintenance burden is low
authselectwith itswithout-nullokfeature flag — the supported RHEL mechanism purpose-built for this (authselect/authselect#94, landed in 2018)Scope
This is intentionally narrow. We understand the concern about carrying hardening overrides that diverge from RHEL defaults and create ongoing maintenance. This is not the start of a campaign to upstream every compliance checklist item into RHCOS.
A small number of changes like this one — high severity, universally agreed upon across benchmarks, zero functional risk, and using existing RHEL tooling — are worth considering. We're happy to discuss which additional items (if any) would meet that bar in separate conversations.
References
without-nullokfeature: authselect/authselect@e1fbbdc