Description of problem: SSSD will not start due to incorrect permissions when the DISA STIG is applied. This breaks anything using SSSD like IdM. Version-Release number of selected component (if applicable): 9.2 How reproducible: Consistant Steps to Reproduce: 1.Install DISA STIG whether it is via the security profile at install or with openscap 2. 3. Actual results: [root@idm ~]# ll /etc/sssd/sssd.conf -rw-r--r--. 1 root root 62 May 9 08:57 /etc/sssd/sssd.conf [root@idm ~]# systemctl status sssd × sssd.service - System Security Services Daemon Loaded: loaded (/usr/lib/systemd/system/sssd.service; enabled; preset: enabled) Active: failed (Result: exit-code) since Tue 2023-05-16 10:58:35 EDT; 2 weeks 1 day ago Main PID: 1136 (code=exited, status=4) CPU: 75ms May 16 10:58:35 idm.tests.example.com systemd[1]: Starting System Security Services Daemon... May 16 10:58:35 idm.tests.example.com sssd[1136]: SSSD couldn't load the configuration database [1432158322]: File ownership and permissions check failed May 16 10:58:35 idm.tests.example.com systemd[1]: sssd.service: Main process exited, code=exited, status=4/NOPERMISSION May 16 10:58:35 idm.tests.example.com systemd[1]: sssd.service: Failed with result 'exit-code'. May 16 10:58:35 idm.tests.example.com systemd[1]: Failed to start System Security Services Daemon. Expected results: [root@idm ~]# ll /etc/sssd/sssd.conf -rw-------. 1 root root 551 May 31 13:29 /etc/sssd/sssd.conf [root@idm ~]# systemctl status sssd ● sssd.service - System Security Services Daemon Loaded: loaded (/usr/lib/systemd/system/sssd.service; enabled; vendor preset: enabled) Active: active (running) since Wed 2023-05-31 13:43:59 EDT; 2h 33min ago Main PID: 2385 (sssd) Tasks: 9 (limit: 24868) Memory: 57.1M CGroup: /system.slice/sssd.service ├─2385 /usr/sbin/sssd -i --logger=files ├─2388 /usr/libexec/sssd/sssd_be --domain implicit_files --uid 0 --gid 0 --logger=files ├─2389 /usr/libexec/sssd/sssd_be --domain demo.example.com --uid 0 --gid 0 --logger=files ├─2391 /usr/libexec/sssd/sssd_nss --uid 0 --gid 0 --logger=files ├─2392 /usr/libexec/sssd/sssd_pam --uid 0 --gid 0 --logger=files ├─2393 /usr/libexec/sssd/sssd_ifp --uid 0 --gid 0 --logger=files ├─2394 /usr/libexec/sssd/sssd_ssh --uid 0 --gid 0 --logger=files ├─2395 /usr/libexec/sssd/sssd_sudo --uid 0 --gid 0 --logger=files └─2396 /usr/libexec/sssd/sssd_pac --uid 0 --gid 0 --logger=files Additional info:
Hi, SSSD expects that the sssd.conf file has 0600 permissions because the file might contain a password which SSSD is using to connect to an LDAP server. Does DISA STIG require 0644 on sssd.conf? If yes, I think this should be corrected. Please move this ticket to a component which is related to DISA STIG. Thanks. bye, Sumit
(In reply to Sumit Bose from comment #1) > Hi, > > SSSD expects that the sssd.conf file has 0600 permissions because the file > might contain a password which SSSD is using to connect to an LDAP server. > > Does DISA STIG require 0644 on sssd.conf? If yes, I think this should be > corrected. Please move this ticket to a component which is related to DISA > STIG. > > Thanks. > > bye, > Sumit I have found nothing in the DISA STIG that RHEL 9 is currently using, which is the RHEL 8 one, that requires sssd.conf to have 644 permissions.
Mike, what is the request here? As Sumit pointed out, what you describe - is "by design".
(In reply to Alexey Tikhonov from comment #3) > Mike, what is the request here? > > As Sumit pointed out, what you describe - is "by design". I do not know who is responsible, so I assigned this issue to the package. The issue is that once the DISA STIG is installed, for some reason /etc/sssd/sssd.conf permissions change from 0600 to 0644. I did not find any rules in the DISA STIG that would account for this change. Nothing specific to sssd.conf, nor the filesystem. I do not know what is causing the permission change. This permission change causes SSSD to fail to start.
(In reply to Mike Ralph from comment #4) > > I do not know what is causing the > permission change. Could you please try using `inotifywait` or similar tool to capture a momemnt when attributes are changed and thus, hopefully, to figure out what action leads to this?
Hi, can you try to ask the customer to call oscap xccdf generate fix --profile stig /usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xml > stig.bash and send stig.bash? bye, Sumit
Hi, thanks for the script, if I run this on a system which does not have a /etc/sssd/sssd.conf file, i.e. sssd-common package is installed but SSSD is not configured, there will be a # ls -alZ /etc/sssd/sssd.conf -rw-r--r--. 1 root root unconfined_u:object_r:sssd_conf_t:s0 62 Jun 2 14:10 /etc/sssd/sssd.conf # cat /etc/sssd/sssd.conf [pam] offline_credentials_expiration = 1 pam_cert_auth = True From looking at the script I guess the file and the content are created by 'echo' commands which most probably will follow the umask the script is running under. I guess the script should add a 'chmod 600 /etc/sssd/sssd.conf' at a suitable place similar to 'chmod 600 "$MAIN_CONF"' in xccdf_org.ssgproject.content_rule_sssd_certificate_verification. bye, Sumit
Hi Mike, can you check if in your case /etc/sssd/sssd.conf did not exist at the time the DISA STIG was applied? Thanks. bye, Sumit
(In reply to Sumit Bose from comment #9) > Hi Mike, > > can you check if in your case /etc/sssd/sssd.conf did not exist at the time > the DISA STIG was applied? > > Thanks. > > bye, > Sumit Sumit, On a system that has not had the DISA STIG applied, there os no sssd.conf Before DISA STIG install: [root@idm ~]# ll /etc/sssd/ total 0 drwx--x--x. 2 sssd sssd 6 Jan 16 10:20 conf.d drwx--x--x. 2 root root 6 Jan 16 10:20 pki
(In reply to Mike Ralph from comment #10) > > On a system that has not had the DISA STIG applied, there os no sssd.conf > Before DISA STIG install: > [root@idm ~]# ll /etc/sssd/ > total 0 > drwx--x--x. 2 sssd sssd 6 Jan 16 10:20 conf.d > drwx--x--x. 2 root root 6 Jan 16 10:20 pki (In reply to Sumit Bose from comment #8) > > From looking at the script I guess the file and the content are created by > 'echo' commands which most probably will follow the umask the script is > running under. I guess the script should add a 'chmod 600 > /etc/sssd/sssd.conf' at a suitable place similar to 'chmod 600 "$MAIN_CONF"' > in xccdf_org.ssgproject.content_rule_sssd_certificate_verification. Mike, please move this ticket to a component which is related to DISA STIG.
Fixed upstream: https://github.com/ComplianceAsCode/content/pull/10695