Description of problem: If a user is added to the SSSD BE database, but no password is set. The user can ssh to the SSSD configured client and enter any password and get in. TESTED CONFIGURATION system-auth configuration: auth required pam_env.so auth sufficient pam_fprintd.so auth sufficient pam_unix.so nullok auth sufficient pam_sss.so use_first_pass auth requisite pam_succeed_if.so uid >= 500 quiet auth required pam_deny.so account required pam_unix.so broken_shadow account sufficient pam_sss.so account sufficient pam_localuser.so account sufficient pam_succeed_if.so uid < 500 quiet account required pam_permit.so password requisite pam_cracklib.so try_first_pass retry=3 password sufficient pam_unix.so sha512 shadow nullok use_authtok password sufficient pam_sss.so use_first_pass password required pam_deny.so session optional pam_keyinit.so revoke session required pam_limits.so session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid session sufficient pam_unix.so session required pam_sss.so sssd configuration: [services] description = Local Service Configuration activeServices = nss, pam reconnection_retries = 3 [services/nss] description = NSS Responder Configuration filterGroups = root filterUsers = root debug-level = 4 [services/dp] description = Data Provider Configuration debug-level = 4 [services/pam] description = PAM Responder Configuration [services/monitor] description = Service Monitor Configuration [domains] description = Domains served by SSSD domains = LOCAL [domains/LOCAL] description = LOCAL Users domain enumerate = 1 minId = 1000 maxId = 1010 legacy = FALSE magicPrivateGroups = TRUE provider = local Version-Release number of selected component (if applicable): sssd-0.4.1-1.fc11.i586 How reproducible: always Steps to Reproduce: 1. yum install sssd 2. edit system-auth (as above) and nsswitch.conf as required 3. modify /etc/sssd/sssd.conf as above 4. service start sssd 5. sss_useradd -u 1000 -h /home/myuser -b /bin/bash myuser 6. from a remote machine ssh to the sssd client machine sssh myuser 7. at password prompt enter anything you would like Actual results: ssh session is successful and user allowed machine access Expected results: password to be denied, user not allowed machine access Additional info: If you subsequently set the user password on the sssd client machine (passwd myuser) a bad password denies access and the correct password allows access.
Ok, this is a bit of a tricky bug to reproduce. The described behavior is unique to i586 (it does not occur on x86_64 systems). Furthermore the bug only occurs when running the sssd daemonized (with the -D option). It does not manifest when running in debug mode. Further investigation is needed.
Created attachment 355410 [details] Patch to ensure proper return from password check Ok, I've tracked down the issue here. In the LOCAL authentication check, we evaluate whether the LOCAL backend has a password set for the user. It looks like there was a copy-paste error that resulted in us returning early from the authentication evaluation with a success code instead of an error code. I have now corrected it so that we explicitly set the return code to LDB_ERR_NO_SUCH_ATTRIBUTE when the password is missing. Could someone from the security response team please review the attached patch? It should apply cleanly against the SSSD 0.4.1 SRPM sources in CVS.
Created attachment 355424 [details] Patch to ensure proper return from password check Replacing old patch with new one that lists CVE in the commit message.
Built in Koji, submitted for stable. http://koji.fedoraproject.org/koji/buildinfo?buildID=124518
sssd-0.4.1-3.fc11 has been pushed to the Fedora 11 stable repository. If problems still persist, please make note of it in this bug report.