Rule file_permissions_sshd_private_key is not aligned with DISA's check for RHEL-08-010490

yuumasato commented 2 years ago

Description of problem:

STIG RHEL-08-010490 states that private SSH host keys should have mode 0600 or less. After #9094 the rule file_permissions_sshd_private_key started to allow the private keys to have:

mode 0600 and group root; or
mode 0640 and group ssh_keys

By default the RHEL-8 keys are assigned to group ssh_keys, so all SSH private keys are allowed to have mode 06400. But the RHEL8 STIG requires all private SSH host keys to have mode 0600 or less permissive.

Note that the STIG item is about private SSH host keys, i.e.: /etc/ssh/ssh_host_*_key. While rule file_permissions_sshd_private_key is about all private keys, host's and user's.

Also note that the STIG item lists the keys as owned by group ssh_keys, and still wants the rules to have mode 0600

SCAP Security Guide Version:

5caa381157e979f65cba48f5561beab8fa84c75d

Operating System Version:

RHEL-7 and RHEL-8

Steps to Reproduce:

Have a clean RHEL-8 system

oscap-ssh rhel8 22 xccdf eval --remediate --profile 'stig' --rule xccdf_org.ssgproject.content_rule_file_permissions_sshd_private_key --report /tmp/report.html --oval-results --results /tmp/results.xml build/ssg-rhel8-ds.xml


Copying input file 'build/ssg-rhel8-ds.xml' to remote working directory '/tmp/tmp.EzZSeT40xR'...
ssg-rhel8-ds.xml                                                                                                                                                                                                                                                                            100%   23MB 377.2MB/s   00:00    
Starting the evaluation...
WARNING: Datastream component 'scap_org.open-scap_cref_security-data-oval-com.redhat.rhsa-RHEL8.xml.bz2' points out to the remote 'https://access.redhat.com/security/data/oval/com.redhat.rhsa-RHEL8.xml.bz2'. Use '--fetch-remote-resources' option to download it.
WARNING: Skipping 'https://access.redhat.com/security/data/oval/com.redhat.rhsa-RHEL8.xml.bz2' file which is referenced from datastream
WARNING: Skipping ./security-data-oval-com.redhat.rhsa-RHEL8.xml.bz2 file which is referenced from XCCDF content
--- Starting Evaluation ---

Title Verify Permissions on SSH Server Private *_key Key Files Rule xccdf_org.ssgproject.content_rule_file_permissions_sshd_private_key Ident CCE-82424-3 WARNING: Skipping ./security-data-oval-com.redhat.rhsa-RHEL8.xml.bz2 file which is referenced from XCCDF content Result pass

--- Starting Remediation ---

oscap exit code: 0

4. oscap-ssh rhel8 22 xccdf eval --rule xccdf_mil.disa.stig_rule_SV-230287r743951_rule  --report /tmp/report.html --oval-results --results /tmp/results.xml shared/references/disa-stig-rhel8-v1r5-xccdf-scap.xml

Copying input file 'shared/references/disa-stig-rhel8-v1r5-xccdf-scap.xml' to remote working directory '/tmp/tmp.xxT4DBB2um'... Starting the evaluation... --- Starting Evaluation ---

Title The RHEL 8 SSH private host key files must have mode 0600 or less permissive. Rule xccdf_mil.disa.stig_rule_SV-230287r743951_rule Ident CCI-000366 Result fail

oscap exit code: 2



#### Actual Results:
Our rule that supports RHEL-08-010490 reports `pass`
DISA's check for RHEL-08-010490 reports `fail`

#### Expected Results:
Both benchmarks report pass.

#### Additional Information/Debugging Steps:
While the scope of our rule is larger than the STIG item, i.e.: the STIG is about host's keys, and our rule is about both user's and host's keys, rule `file_permissions_sshd_private_key` can stil lbe used to cover `RHEL-08-010490`.

I guess we should talk to DISA about this....
CC @ggbecker @matejak 

This problem occurs also with the "STIG with GUI" profile.

yuumasato commented 2 years ago

Alignment of RHEL-7 is also affected: https://stigs.mab879.com/products/rhel7/v3r8/RHEL-07-040420/

yuumasato commented 2 years ago

In the RHEL-8 CIS, and very likely in other CIS benchmarks as well, the requirement for SSH private host keys is aligned with current behavior of file_permissions_sshd_private_key.

For example, 5.2.2 Ensure permissions on SSH private host key files are configured (Automated):

Audit:
Note: Either mode 0640 with owner root and group ssh_keys OR mode 0600 with owner
root and group root is acceptable
Run the following command and verify either:
Uid is 0/root and Gid is /ssh_keys and permissions 0640 or more restrictive:
OR
Uid is 0/root and Gid is 0/root and permissions are 0600 or more restrictive:

matejak commented 2 years ago

Could you please check https://github.com/ComplianceAsCode/content/issues/7833#issuecomment-1158692192? It seems to me that Milan's comment and DISA content are in a contradiction.

I can imagine that the rule could be parametrized by a variable listing allowed group owners, but it would make it pretty difficult write and to test, so we should avoid it if possible.

yuumasato commented 2 years ago

@matejak I don't see the contradiction, could you be more specific?

In his comment, he says that CIS recommends:

mode 0640 when group owner is ssh_keys; and
mode 0600 when group owner is root.

And our rule does exactly that.

DISA wants the mode to be 0600, no matter the group owner.

When our rule scans the system, it lets the keys live with mode 0640, because they have gropu owner ssh_keys. Result is pass. But DISA's check scans the system and finds rules with mode 0640. Result is fail.

In other words, the rule would have to behave differently per profile, not per product. The variable with allowed groups could be one way solve this issue; the other way could be to convince DISA to accept private SSH host keys with mode 0640 when group owner is ssh_keys.

yuumasato commented 2 years ago

I see the contradiction now:

> No. STIG doesn't mention group at all and mode is 0640 or less permissive https://www.stigviewer.com/stig/red_hat_enterprise_linux_8/2020-11-25/finding/V-230287

And I think the problem is he linked and old release of the STIG from 2020-11-25. This one is the latest release, from few days ago: https://stigs.mab879.com/products/rhel8/v1r7/RHEL-08-010490/

matejak commented 2 years ago

OK, so it's now clear what is the situation. The question therefore is - what to do with it? What are the options? Do we want to target changes in the DISA content as the solution, or should we aim to change the rule?

ggbecker commented 2 years ago

The change in the DISA content should be the target. The community has also asked for this change and I've also asked DISA to update the verbiage to include the ssh_keys+0640 as a valid configuration.

yuumasato commented 1 year ago

This issue has been fixed on DISA's SCAP content Red Hat Enterprise Linux 8 STIG Benchmark - Ver 1, Rel 8. Ref: https://github.com/ComplianceAsCode/content/pull/10078/commits/df24f2352cca70afc107358c62bae3386b66d839

ComplianceAsCode / content