SSSD LDAP sudo provider: unscoped sudoRole search lets any LDAP writer grant themselves root fleet-wide

Impact

With ldap_sudo_search_base left unconfigured, SSSD searches the whole directory tree for sudoRole objects, so a sudoRole planted anywhere an attacker can write is honoured. Anyone holding write access to any subtree can therefore mint a rule granting themselves root via sudo on every host enrolled in that directory. HPC and GPU clusters commonly enrol all login, storage and compute nodes against one LDAP or IPA tree, which makes this a single-write-to-whole-fleet-root path rather than a per-host issue. The rule takes effect on hosts the attacker never touched and leaves an ordinary successful sudo in the logs.

Who can reach it

An authenticated directory user with write access to any subtree of the LDAP directory SSSD searches. No access to the target hosts is needed beforehand - the attacker then logs in as themselves and runs sudo.

What to do

Apply the sssd errata for your RHEL stream (RHSA-2026:41937, :42122, :46482, :46990, :49839 cover the affected releases) and restart sssd; clear the sssd cache so stale sudo rules are not served. Independently, set ldap_sudo_search_base explicitly to the OU that legitimately holds sudoRole objects - that is the durable fix and it is a config change plus daemon restart, no reboot and no node drain. Audit the directory for sudoRole objects outside the intended subtree before declaring the fleet clean.

References