Harden sshd crypto policy

[vojtapolasek]

Description:

Added a new rule to harden SSHD by applying stricter crypto policy.

Rationale:

Athering to the CC requirements, based on Kickstart file.

[openscap-ci]

Can one of the admins verify this patch?

[yuumasato]

@openscap-ci add to whitelist

[yuumasato]

Please, look into adding test scenarios;

Add the OCIL clause and question;
This can serve as inspiration.
The ocil_clause should be the continuation of the question:
Is it the case that....?

And make sure the files have a newline at the end.

[matejak]

test this please

[yuumasato]

@vojtapolasek Thank you for the updates.
Just a few more fixes to the rule text, and it should be good to go.

[yuumasato]

@vojtapolasek Thank you!

[ggbecker]

Customizing the crypto policy file for opensshserver will require changes in our enable_fips_mode OVAL check as it tests the file if it is a symlink to the default file as you can see here:

https://github.com/ComplianceAsCode/content/blob/master/linux_os/guide/system/software/integrity/fips/enable_fips_mode/oval/shared.xml#L16
https://github.com/ComplianceAsCode/content/blob/master/linux_os/guide/system/software/integrity/crypto/configure_crypto_policy/oval/shared.xml#L59

Otherwise the enable_fips_mode rule will always fail when this new rule is selected.

@yuumasato what do you think about this?

[adelton]

@ggbecker, yes, you are right.

[yuumasato]

Customizing the crypto policy file for opensshserver will require changes in our enable_fips_mode OVAL check as it tests the file if it is a symlink to the default file as you can see here:

Yes, customization of crypto policies fails the check for those symlinks in configure_crypto_policy.

We can consider dropping all the symlink checks, not being symlinked to a back-end policy does not imply malicious tampering of the policy.

[adelton]

Alternatively, the check could be for the symlink, or the drop-in snippet file we know we support.

[vojtapolasek]

@adelton I agree with this, I find is as the safest option. However, in this case we need to track somewhere what policies we modify. Just saying.

[yuumasato]

the drop-in snippet file we know we support

How will the rule know that what is in the drop-in snippet is OK?
This seems out of scope of what configure_crypto_policy should be doing.

If a rule adds a drop-in replacement for a back-end, shouldn't that rule check it?

[adelton]

How will the rule know that what is in the drop-in snippet is OK?

It won't. But it will know that the snippet is allowed, and thus the check for the symlink does not make sense.

This seems out of scope of what configure_crypto_policy should be doing.

If a rule adds a drop-in replacement for a back-end, shouldn't that rule check it?

Well, it does, functionally. The harden_sshd_crypto_policy rule checks if the result in /etc/crypto-policies/back-ends/opensshserver.config (be it symlink or file) has the content it expects. So it checks the ultimate result that the sshd will use.