-
Notifications
You must be signed in to change notification settings - Fork 92
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix(5.2.2): ensured correct host key permissions are checked on RedHa… #102
base: master
Are you sure you want to change the base?
fix(5.2.2): ensured correct host key permissions are checked on RedHa… #102
Conversation
…t systems on-behalf-of: @Logicworks <[email protected]> Signed-off-by: Adrian Mlodzianowski <[email protected]>
Just weighing in with some thoughts, the CIS Distribution Independent Linux (DIL) benchmarks v2.0.0 are pretty explicit on this control:
The CIS DIL benchmarks in several scenarios conflict with the recommendations of vendors, and in some cases, the recommendations are plain wrong for certain vendors. I have more than once seen recommendations in DIL that apply to one flavor of Linux, but do not really apply to another version of Linux. (E.g., stuff like "the file at That being said, considering the CIS benchmarks for RHEL, CentOS and DIL all discourage host-based authentication, I am of the opinion that the keys really should be 0600 on all platforms. |
I totally understand this approach and I was a little hesitant to even open this PR in the first place since this is a pretty grey area in my mind. While the CIS DIL and CIS RHEL 8 benchmarks both clearly state the desired permissions as 0600 with root:root ownership, CIS themselves are inconsistent with the implementation. The RHEL 8 Build Kit provided by CIS (v1.0.0) has a bash function
And the fix:
Additionally, we tested the AWS Marketplace RHEL 8 CIS Level 1 AMI which has the same problem - all private host key files have 0640 In any case, I completely agree with your point that this is an issue with the CIS DIL benchmark itself, not the dev-sec implementation of this control which is completely correct. If the goal of this project is to keep the dev-sec profile true to the benchmark and drop edge cases like this (which could turn into a maintenance nightmare) then I will close this PR out. |
@amlodzianowski you definitely raise a good point, with regard to the build kit and the marketplace CIS level 1 AMI. (I had not looked at the RHEL 8 implementations or remediation kits, as I am a CentOS user, and, well, we all know what's going on with CentOS Stream 🙄) I wonder if there are other Linux distributions that recommend a group like "ssh_keys". If there are, then perhaps dev-sec could add something attribute-based, allowing users to specify whether there should be a group allowed access to their keys. Something like: if group_allowed_access.nil?
it { should_not be_more_permissive_than('0600') }
else
# non-nil group specified
its('group') { should eq group_allowed_access }
it { should_not be_more_permissive_than('0640') }
end In any event, to be clear, I am not a |
While the CIS DIL Benchmark expects 0600 root:root permissions on all private host key files, this appears to be undesired behavior on RedHat systems where the openssh package creates ssh host key files with the group ssh_keys and permissions 0640 for user host-based ssh authentification to work (the setuid helper program /usr/libexec/openssh/ssh-keysign is used to read the keys and requires these permissions).
We are thinking that instead of waivering this control ourselves, this profile should be updated to reflect the recommended RedHat configuration.
Relevant issues:
https://bugzilla.redhat.com/show_bug.cgi?id=1372070
ComplianceAsCode/content#1542
https://github.com/ComplianceAsCode/content/pull/1556/files
xcat2/xcat-core#2617