Bug 2211511
| Summary: | RHEL 9.2 SSSD permissions wrong when DISA STIG is applied | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 9 | Reporter: | Mike Ralph <mralph> |
| Component: | scap-security-guide | Assignee: | Gabriel Gaspar Becker <ggasparb> |
| Status: | CLOSED ERRATA | QA Contact: | Milan Lysonek <mlysonek> |
| Severity: | high | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 9.2 | CC: | atikhono, ggasparb, jcerny, jjaburek, mburket, mhaicman, mlysonek, openscap-maint, pbrezina, sbose, vpolasek |
| Target Milestone: | rc | Keywords: | Triaged |
| Target Release: | --- | Flags: | pm-rhel:
mirror+
|
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
| Fixed In Version: | scap-security-guide-0.1.69-1.el9 | Doc Type: | No Doc Update |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2023-11-07 08:37:02 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
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 Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (scap-security-guide bug fix and enhancement update), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2023:6552 |
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: