Bug 2002850

Summary: The CIS profile sets /etc/ssh/*key to 640 which prevents sshd from starting
Product: Red Hat Enterprise Linux 8 Reporter: jcastran
Component: scap-security-guideAssignee: Vojtech Polasek <vpolasek>
Status: CLOSED ERRATA QA Contact: Milan Lysonek <mlysonek>
Severity: urgent Docs Contact: Khushbu Borole <kborole>
Priority: unspecified    
Version: 8.4CC: ggasparb, jafiala, kborole, matyc, mhaicman, mlysonek, wsato
Target Milestone: rcKeywords: AutoVerified, Triaged
Target Release: ---   
Hardware: All   
OS: Linux   
Fixed In Version: scap-security-guide-0.1.59-1.el8 Doc Type: Bug Fix
Doc Text:
.CIS profile no longer blocks the SSH service Previously, the `xccdf_org.ssgproject.content_rule_file_permissions_sshd_private_key` rule by default set the permissions to `640` on SSH private keys. As a consequence, the SSH daemon did not start. This update removes the `file_permissions_sshd_private_key` rule from the CIS profile and as a result, the SSH service works correctly.
Story Points: ---
Clone Of: Environment:
Last Closed: 2022-05-10 14:14:34 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:

Description jcastran 2021-09-09 20:23:56 UTC
Description of problem:
This rule:
<xccdf-1.2:fix id="file_permissions_sshd_private_key" system="urn:xccdf:fix:script:puppet">include ssh_private_key_perms

Sets the permissions to 640 for /etc/ssh/*key

class ssh_private_key_perms {
  exec { 'sshd_priv_key':
    command =&gt; "chmod 0640 /etc/ssh/*_key",
    path    =&gt; '/bin:/usr/bin'

Which then stops sshd from running because sshd does not want any permission on Group or Other.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Apply the CIS profile
2. systemctl restart sshd

Actual results:
# systemctl restart sshd
  Job for sshd.service failed because the control process exited with error code.
  See "systemctl status sshd.service" and "journalctl -xe" for details.

# journalctl -xe
  -- Unit sshd.service has begun starting up.
  Sep 09 13:56:44 r8 sshd[747733]: @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
  Sep 09 13:56:44 r8 sshd[747733]: @         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
  Sep 09 13:56:44 r8 sshd[747733]: @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
  Sep 09 13:56:44 r8 sshd[747733]: Permissions 0640 for '/etc/ssh/ssh_host_rsa_key' are too open.
  Sep 09 13:56:44 r8 sshd[747733]: It is required that your private key files are NOT accessible by others.
  Sep 09 13:56:44 r8 sshd[747733]: This private key will be ignored.
  Sep 09 13:56:44 r8 sshd[747733]: Unable to load host key "/etc/ssh/ssh_host_rsa_key": bad permissions
  Sep 09 13:56:44 r8 sshd[747733]: Unable to load host key: /etc/ssh/ssh_host_rsa_key

Expected results:
The profile should not change the keys to 640. There appears to be caveats for other os's

    name: file_permissions
        filepath: /etc/ssh/
        missing_file_pass: 'true'
        file_regex: ^.*_key$
        filemode: '0640'
        filemode@sle12: '0600'
        filemode@sle15: '0600'
        filemode@ubuntu1604: '0600'
        filemode@ubuntu1804: '0600'
        filemode@ubuntu2004: '0600'

The default should be 600 instead of fixing this per os since the default is not a valid permission for sshd.

Additional info:


Comment 1 Gabriel Gaspar Becker 2021-09-13 16:12:45 UTC
This rule is incorrectly being used by the CIS profile provided in scap-security-guide package. The RHEL8 CIS benchmark reference number 5.2.3 states that the permissions should be 0600 and also owner and group owner should be root:root.

This rule only works when the group owner of /etc/ssh/*_key files is set to ssh_keys which is the default for a clean RHEL installation. But there are some cases where regenerated keys are created with root group owner and the rule file_permissions_sshd_private_key is not aware of it. Later versions of this content unselect this rule from the CIS profile because it's not aligned. A new rule is probably going to be created to fully fulfill the CIS requirement.

DISA STIG states that the permissions should be 0640 for these files, hence the conflict and need for a new rule.

Comment 3 Vojtech Polasek 2021-09-14 08:52:52 UTC
This has been fixed upstream by removing the problematic rule from the profile:
We need a new rule which will work properly.

Comment 4 Watson Yuuma Sato 2021-10-19 11:49:54 UTC
I believe this patch addresses the bug: https://github.com/ComplianceAsCode/content/pull/7742

Comment 18 errata-xmlrpc 2022-05-10 14:14:34 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.