=============== A security bug in SSSD 1.8 and later =========================
Subject: information leak from the sssd-sudo responder
CVE ID: CVE-2018-10852
Summary: The UNIX socket that is used for communication between the sudo utility and the sssd-sudo responder had its permissions set to world-readable and writable, which means that anyone who can send a message using the same raw protocol that sudo and SSSD use can read the sudo rules available for any user.
Impact: low
Affects default configuration: When configured with tools like ipa-client-install
Introduced with: SSSD 1.8
== Description == SSSD uses a UNIX pipe, typically located at /var/lib/sss/pipes/sudo for communication between sudo and the sssd-sudo responder. When SSSD created this pipe, the umask() call was set to be too permissive, which resulted in the pipe being readable and writable. Then, if an attacker used the same communication protocol that sudo uses to talk to SSSD, they could obtain the list of sudo rules for any user who stores their sudo rules in a remote directory.
While the sudo responder is not started by default by SSSD itself, utilities like ipa-client-install configure the sudo responder to be started.
One way of mitigating the issue would be, for systems that run a recent SSSD version and use the systemd service manager to remove sudo from the list of services started by SSSD, then augment the sssd-sudo.socket service file with the “SocketMode=0600” directive and finally configure the sssd-sudo socket to be activated by systemd (systemctl enable sssd-sudo.socket).
== Patch avaliability === * master: https://pagure.io/SSSD/sssd/c/ed90a20a0f0e936eb00d268080716c0384ffb01d * sssd-1-14: https://pagure.io/SSSD/sssd/c/3a0397b4c2b2d9c47e8bd0da808f5a1797244439 * sssd-1-13: https://pagure.io/SSSD/sssd/c/b0614512bee0b07ab1ab9c314220402c7c4680ac
sssd-users@lists.fedorahosted.org