RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 2211511 - RHEL 9.2 SSSD permissions wrong when DISA STIG is applied
Summary: RHEL 9.2 SSSD permissions wrong when DISA STIG is applied
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 9
Classification: Red Hat
Component: scap-security-guide
Version: 9.2
Hardware: All
OS: All
unspecified
high
Target Milestone: rc
: ---
Assignee: Gabriel Gaspar Becker
QA Contact: Milan Lysonek
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2023-05-31 20:19 UTC by Mike Ralph
Modified: 2023-11-07 10:08 UTC (History)
11 users (show)

Fixed In Version: scap-security-guide-0.1.69-1.el9
Doc Type: No Doc Update
Doc Text:
Clone Of:
Environment:
Last Closed: 2023-11-07 08:37:02 UTC
Type: Bug
Target Upstream Version:
Embargoed:
pm-rhel: mirror+

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker RHELPLAN-158751 0 None None None 2023-05-31 20:22:45 UTC
Red Hat Product Errata RHBA-2023:6552 0 None None None 2023-11-07 08:37:35 UTC

Description Mike Ralph 2023-05-31 20:19:33 UTC 
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:
Comment 1 Sumit Bose 2023-06-01 05:49:29 UTC 
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
Comment 2 Mike Ralph 2023-06-01 13:13:35 UTC 
(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.
Comment 3 Alexey Tikhonov 2023-06-02 10:59:04 UTC 
Mike, what is the request here?

As Sumit pointed out, what you describe - is "by design".
Comment 4 Mike Ralph 2023-06-02 11:54:18 UTC 
(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.
Comment 5 Alexey Tikhonov 2023-06-02 12:07:20 UTC 
(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?
Comment 6 Sumit Bose 2023-06-02 13:19:54 UTC 
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
Comment 8 Sumit Bose 2023-06-02 18:17:55 UTC 
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
Comment 9 Sumit Bose 2023-06-05 06:00:35 UTC 
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
Comment 10 Mike Ralph 2023-06-05 11:23:16 UTC 
(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
Comment 11 Alexey Tikhonov 2023-06-06 10:29:01 UTC 
(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.
Comment 15 Gabriel Gaspar Becker 2023-07-18 09:42:49 UTC 
Fixed upstream: https://github.com/ComplianceAsCode/content/pull/10695
Comment 31 errata-xmlrpc 2023-11-07 08:37:02 UTC 
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
Note You need to log in before you can comment on or make changes to this bug.