7.238. sssd
Updated sssd packages that fix two security issues, multiple bugs, and add various enhancements are now available for Red Hat Enterprise Linux 6.
The Red Hat Security Response Team has rated this update as having low security impact. Common Vulnerability Scoring System (CVSS) base scores, which give detailed severity ratings, are available for each vulnerability from the CVE links associated with each description below.
The System Security Services Daemon (SSSD) provides a set of daemons to manage access to remote directories and authentication mechanisms. It provides an NSS and PAM interface toward the system and a pluggable back-end system to connect to multiple different account sources. It is also the basis to provide client auditing and policy services for projects such as FreeIPA.
Note
The sssd packages have been upgraded to upstream version 1.9.2, which provides a number of bug fixes and enhancements over the previous version. BZ#827606
Security Fixes
- CVE-2013-0219
- A race condition was found in the way SSSD copied and removed user home directories. A local attacker who is able to write into the home directory of a different user who is being removed could use this flaw to perform symbolic link attacks, possibly allowing them to modify and delete arbitrary files with the privileges of the root user.
- CVE-2013-0220
- Multiple out-of-bounds memory read flaws were found in the way the autofs and SSH service responders parsed certain SSSD packets. An attacker could spend a specially-crafted packet that, when processed by the autofs or SSH service responders, would cause SSSD to crash. This issue only caused a temporary denial of service, as SSSD was automatically restarted by the monitor process after the crash.
The CVE-2013-0219 and CVE-2013-0220 issues were discovered by Florian Weimer of the Red Hat Product Security Team.
Bug Fixes
- BZ#854619
- When SSSD was built without sudo support, the ldap_sudo_search_base value was not set and the namingContexts LDAP attribute contained a zero-length string. Consequently, SSSD tried to set ldap_sudo_search_base with this string and failed. Therefore, SSSD was unable to establish a connection with the LDAP server and switched to offline mode. With this update, SSSD considers the zero-length namingContexts value the same way as if no value is available; thus preventing this bug. Note that this issue was primarily affecting Novell eDirectory server users.
- BZ#840089
- When the ldap_chpass_update_last_change option was enabled, the shadowLastChange attribute contained a number of seconds instead of days. Consequently, when shadowLastChange was in use and the user was prompted to update their expiring password, shadowLastChange was not updated. The user then continued to get an error until they were locked out of the system. With this update, the number of days is stored in shadowLastChange attribute and users are able to change their expiring passwords as expected.
- BZ#847039
- When the kpasswd server was configured but was unreachable during authentication, SSSD considered it the same way as if the KDC server was unreachable. As a consequence, the user failed to authenticate. Now, SSSD considers an unreachable kpasswd server as a fatal error only when performing a password change and users can log in successfully.
- BZ#847043
- Previously, canceling a pthread which was in the midst of any SSS client usage could leave the client mutex locked. As a consequence, the next call to any SSS function became unresponsive, waiting for the mutex to unlock. With this update, a more robust mutex is used, and canceling such a pthread no longer keeps the client mutex locked.
- BZ#872324
- When SSSD created an SELinux login file, it erroneously kept the file descriptor of this file opened. As a consequence, the number of the file descriptors used by SSSD increased every time a user logged in. SSSD now closes the file descriptor when it is no longer needed, thus protecting it from leaking.
- BZ#801719
- Previously, reverse DNS lookup was not performed to get the Fully Qualified Domain Name (FQDN) of a host specified by an IP address. As a consequence, SSH host public key lookup was incorrectly attempted with the textual IP address as an FQDN. Reverse DNS lookup is now performed to get the FQDN of the host before the SSH host public key lookup. SSH host public key lookup now functions correctly using the FQDN of the host.
- BZ#857108
- Kerberos options were loaded separately in the krb5 utility and the IPA provider with different code paths. The code was fixed in krb5 but not in the IPA provider. Consequently, a Kerberos ticket was not renewed in time when IPA was used as an authentication provider. With this update, Kerberos options are loaded using a common API and Kerberos tickets are renewed as expected in the described scenario.
- BZ#849081
- When SSSD was configured to use SSL during communication with an LDAP server and the initialization of SSL failed, SSSD kept the connection to the LDAP server opened. As a consequence, the number of connections to the LDAP server was increased with every request via SSSD, until the LDAP server ran out of available file descriptors. With this update, when the SSL initialization fails, SSSD closes the connection immediately and the number of connections does not grow.
- BZ#819057
- If the LDAP provider was configured to use GSSAPI authentication but the first configured Kerberos server to authenticate against was offline, then SSSD did not retry the other, possibly working servers. The failover code was amended so that all Kerberos servers are tried when GSSAPI authentication is performed in the LDAP provider. The LDAP provider is now able to authenticate against servers that are only configured as failover.
- BZ#822404
- Previously, SSSD did not use the correct attribute mapping when a custom schema was used. As a consequence, if the administrator configured SSSD with a custom attribute map, the autofs integration did not work. The attribute mapping was fixed and SSSD now works with a custom attribute schema.
- BZ#826192, BZ#827036
- In some cases, the SSSD responder processes did not properly close the file descriptors they used to communicate with the client library. As a consequence, the descriptors leaked, and, over time, caused denial of service because SSSD reached the limit of open file descriptors defined in the system. SSSD now proactively closes file descriptors that were not active for some time, making the file descriptor usage consistent.
- BZ#829742
- The SSSD back-end process kept a pointer to the server it was connected to in all cases, even when the server entry was about to expire. Most customers encountered this issue when SRV resolution was enabled. As a consequence, when the server entry expired while SSSD was using it, the back-end process crashed. An additional check has been added to SSSD to ensure the server object is valid before using it. SSSD no longer crashes when using SRV discovery.
- BZ#829740
- When the SSSD daemon was in the process of starting, the parent processes quit right after spawning the child process. As a consequence, the init script printed [OK] after the parent process terminated, which was before SSSD was actually functional. After this update, the parent processes are not terminated until all worker processes are up. Now, the administrator can start using SSSD after the init script prints [OK].
- BZ#836555
- Previously, SSSD always treated the values of attributes that configure the "shadow" LDAP password policy as absolute. As a consequence, an administrator could not configure properties of the "shadow" LDAP password policy as "valid forever". The LDAP "shadow" password attributes are now extended to also allow "-1" as a valid value and an administrator can use the reserved value of "-1" as a "valid forever".
- BZ#842753
- When a service with a protocol was requested from SSSD, SSSD performed access to an unallocated memory space, which caused it to occasionally crash during service lookup. Now, SSSD does not access unallocated memory and no longer crashes during service lookups.
- BZ#842842
- When the LDAP user record contained an empty attribute, the user was not stored correctly in the SSSD cache. As a consequence, the user and group memberships were missing. After this update, empty attributes are not considered an error and the user is stored correctly in the SSSD cache. As a result, the user is present and the group membership can be successfully evaluated.
- BZ#845251
- When multiple servers were configured and SSSD was unable to resolve the host name of a server, it did not try the next server in the list. As a consequence, SSSD went offline even when a working server was present in the configuration file after the one with the unresolvable hostname. SSSD now tries the next server in the list and failover works as expected.
- BZ#847332
- Previously, the description of ldap_*_search_base options in the sssd-ldap(5) man page was missing syntax details for these options which made it unclear how the search base should be specified. The description of ldap_*_search_base options in sssd-ldap(5) man page has been amended so that the format of the search base is now clear.
- BZ#811984
- If the krb5_canonicalize option was set to True or not present at all in the /etc/sssd/sssd.conf file, the client principal could change as a result of the canonicalization. However, SSSD still saved the original principal. As the incorrect principal was saved, the GSSAPI authentication failed. The Kerberos helper process that saves the principals was amended so that the canonicalized principal is saved if canonicalization is enabled. The GSSAPI binds now work correctly even for cases where the principal is changed as a result of the canonicalization.
- BZ#886038
- Previously, SSSD kept the file descriptors to the log files open. Consequently on occasions like moving the actual log file and restarting the back end, SSSD still kept the file descriptors open. After this update, SSSD closes the file descriptor after child process execution. As a result, after successful start of the back end, the file descriptor to log files is closed.
- BZ#802718
- Previously, the proxy domain type of SSSD allowed looking up a user only by its "primary name" in the LDAP server. If SSSD was configured with a "proxy domain" and the LDAP entry contained more name attributes, only the primary one could be used for lookups. For this update, the proxy provider was enhanced to also handle aliases in addition to primary user names. An administrator can now look up a user by any of his names when using the proxy provider.
- BZ#869013
- The sudo "smart refresh" operation was not performed if the LDAP server did not contain any rule when SSSD was started. As a consequence, newly created sudo rules were found after a longer period of time than the "ldap_sudo_smart_refresh_interval" option displayed. The sudo "smart refresh" operation is now performed and newly created sudo rules are found within the ldap_sudo_smart_refresh_interval time span.
- BZ#790090
- The SSSD "local" domain (id_provider=local) performed a bad check on the validity of the access_provider value. If the access_provider option was set with "permit", which is a correct value, SSSD failed with an error. The check for the access_provider option value has been corrected and SSSD now allows the correct access_provider value for domains with id_provider=local.
- BZ#874579
- Previously, SELinux usermap contexts were not ordered correctly if the SELinux mappings were using HBAC rules as a definition of what users to apply the mapping to and if the Identity Management server was not reachable at the same time. As a consequence, an invalid SELinux context could be assigned to a user. SELinux usermap contexts are now ordered correctly, and the SELinux context is assigned to a user successfully.
- BZ#700805
- If SSSD was configured to locate servers using SRV queries, but the default DNS domain was not configured, SSSD printed a DEBUG message. The DEBUG message, which contained an "unknown domain" string, could confuse the user. The DEBUG messages were fixed so that they specifically report that the DNS domain is being looked up, and only print known domains.
- BZ#871424
- Previously, the chpass_provider directive was missing in the SSSD authconfig API. As a consequence, the authconfig utility was unable to configure SSSD if the chpass_provider option was present in the SSSD configuration file. The chpass_provider option has been included in the SSSD authconfig API and now the authconfig utility does not consider this option to be incorrect.
- BZ#874618
- Previously, the sss_cache tool did not accept fully qualified domain names (FQDN). As a consequence, the administrator was unable to force the expiration of a user record in the SSSD cache with a FQDN. The sss_cache tool now accepts an FQDN and the administrator is able to force the expiration of a user record in the SSSD cache with an FQDN.
- BZ#870039
- Previously, when the sss_cache tool was run after an SSSD downgrade, the cache file remained the same as the one used for the previous version of SSSD. The sss_cache tool could not manipulate the cache file and a confusing error message was printed. The "invalid database version" error message was improved in the sss_cache tool. Now, when an invalid cache version is detected, the sss_cache tool prints a suggested solution.
- BZ#882923
- When the proxy provider did not succeed in finding a requested user, the result of the search was not stored in the negative cache (which stores entries that are not found when searched for). A subsequent request for the same user was not answered by the negative cache, but was rather looked up again from the remote server. This bug had a performance impact. The internal error codes were fixed, allowing SSSD to store search results that yielded no entries into the negative cache. Subsequent lookups for non-existent entries are answered from the negative cache and, by effect, are very fast.
- BZ#884600
- Previously, during LDAP authentication, SSSD attempted to contact all of the servers on the server list if every previous server failed. However, SSSD tried to connect to the next server only if the current connection timed out. SSSD now tries to contact the next server on any error and connection attempts work as expected.
- BZ#861075
- When the sssd_be process was forcefully terminated, the SSSD responder processes failed to reconnect if the attempt was performed before the sssd_be process was ready. This caused the responder to be restarted. Occasionally, the responder restarted several times before sssd_be was ready, hitting the maximum number of restarts threshold, after which it was terminated completely. As a consequence, the SSSD responder was not gracefully restarted. After this update, each restart of the SSSD responder process is done with an increasing delay, so that the sssd_be process has enough time to recover before a responder is restarted.
- BZ#858345
- Previously, the sssd_pam responder was not properly configured to recover from a back end disconnection. The PAM requests that were pending before the disconnection were not canceled. Thus, new requests for the same user were erroneously detected as similar requests and piled up on top of the previous ones. This caused the PAM operation to time out with the following error:
Connection to SSSD failed: Timer Expired
As a consequence, the user could not log in. After this update, pending requests are canceled after disconnection and the user is able to log in when the pam responder reconnects. - BZ#873032
- Previously, the sss_cache utility was not included in the main SSSD package and users were unaware of it, unless they installed the sssd-tools package. After this update, the sss_cache utility has been moved to the sssd package.
- BZ#872683
- When the anonymous bind was disabled and enumeration was enabled, SSSD touched an invalid array element during enumeration because the array was not NULL terminated. This caused the sssd_be process to crash. The array is now NULL terminated and the sssd_be process does not crash during enumeration when the anonymous bind is disabled.
- BZ#870505
- When SSSD was configured with multiple domains, the sss_cache tool searched for an object only in the first configured domain and ignored the others. As a consequence, the administrator could not use the sss_cache utility on objects from an arbitrary domain. The sss_cache tool now searches all domains and the administrator can use the tool on objects from an arbitrary domain.
Enhancements
- BZ#768168, BZ#832120, BZ#743505
- A new ID mapping library that is capable of automatically generating UNIX IDs from Windows Security Identifiers (SIDs) has been added to SSSD. An administrator is now able to use Windows accounts easily in a UNIX environment. Also, a new Active Directory provider that contains the attribute mappings tailored specifically for use with Active Directory has been added to SSSD. When id_provider=ad is configured, the configuration no longer requires setting the attribute mappings manually. A new provider for SSSD has been implemented and the administrator can now set up an Active Directory client without having to know the specific Active Directory attribute mappings. The performance of the Active Directory provider is better than the performance of the LDAP provider, especially during login.
- BZ#789470
- When SSSD failed over to another server in its failover list, it stuck with that server as long as it worked. As a result, if the SSSD failed over to a server in another region, it did not reconnect to a closer server until it was restarted or until the backup server stopped working. The concept of a "backup server" has been introduced to SSSD and if SSSD fails over to a server which is listed as a backup server in the configuration, it periodically tries to reconnect to one of the primary servers.
- BZ#789473
- A new sss_seed utility has been introduced in SSSD. An administrator can save a pre-seeded user entry into the SSSD cache which is used until the user can actually refresh the entry with a non-pre-seeded entry from the directory.
- BZ#768165
- Active Directory uses a nonstandard format when a large group that does not fit into a single "page" is returned. By default, the single page size contains 1500 members and if the response exceeds the page size, the range extension is used. If a group was stored on an Active Directory server which contained more than 1500 members, the response from Active Directory contained the proprietary format which SSSD could not parse. SSSD was improved so that it is able to parse the range extension and can now process groups with more than 1500 group members coming from the Active Directory.
- BZ#766000
- Previously, administrators were forced to distribute SELinux mappings via means that were error prone. Therefore, a centralized store of SELinux mappings was introduced to define which user gets which context after logging into a certain machine. SSSD is able to read mappings from an Identity Management server, process them according to a defined algorithm and select the appropriate SELinux context which is later consumed by the pam_selinux module. The Identity Management server administrator is now able to centrally define SELinux context mappings and the Identity Management clients process the mappings when a user logs in using his Identity Management credentials.
- BZ#813327
- The automounter can be configured to read autofs maps from a centralized server such as an LDAP server. But when the network is down or the server is not reachable, the automounter is unable to serve maps. A new responder has been introduced to SSSD that is able to communicate with the automounter daemon. Automounter can now request the maps via SSSD instead of going directly to the server. As a result, the automounter is able to serve maps even in case of an outage of the LDAP server.
- BZ#761573
- A new sudo responder has been implemented in SSSD as well as a client library in sudo itself. SSSD is able to act as a transparent proxy for serving sudo rules for the sudo binary. Now, when the centralized sudo rules source is not available, for instance when the network is down, SSSD is able to fall back to cached rules, providing transparent access to sudo rules from a centralized database.
- BZ#789507
- Prior to this update, even if a user entry was cached by SSSD, it had to be read from the cache file on the disk. This caused the cache readings to be slow in some performance-critical environments. A new layer of cache, stored in the memory was introduced, greatly improving the performance of returning cached entries.
- BZ#771412
- The pam_pwd_expiration_warning option can be used to limit the number of days a password expiration warning is shown for. However, SSSD did not allow to unconditionally pass any password warning coming from the server to the client. The behavior of pam_pwd_expiration_warning was modified so that if the option is set to 0, it is always passed on to the client, regardless of the value of the warning. As a result, after setting the pam_pwd_expiration_warning option to 0, the administrator will always see the expiration warning if the server sends one.
- BZ#771975
- The force_timeout option has been made configurable and the administrator can now change the force_timeout option for environments where SSSD subprocesses might be unresponsive for some time.
All users of sssd are advised to upgrade to these updated packages, which correct these issues, fix these bugs and add these enhancements.