RootDistanceMax instead of RootDistanceMaxSec

[yvespp]

Describe the bug
According to https://www.freedesktop.org/software/systemd/man/timesyncd.conf.html RootDistanceMax should be called RootDistanceMaxSec

cis-dil-benchmark/controls/2_2_special_purpose_services.rb

Line 136 in 907e58f

its('content') { should match /^RootDistanceMax=[0-9]/ }

[deric4]

According to https://www.freedesktop.org/software/systemd/man/timesyncd.conf.html RootDistanceMax should be called RootDistanceMaxSec

@yvespp is correct. Reviewing the CIS Distribution Independent Linux Benchmark v2.0.0, I can see how this was defined incorrectly:

The Remediation Procedure for 2.2.1.4 - Ensure systemd-timesyncd is configured has the same INCORRECT ❌ config key:

edit the file /etc/systemd/timesyncd.conf and add/modify the following lines:

NTP=0.debian.pool.ntp.org 1.debian.pool.ntp.org #Servers listed should be In Accordence With Local Policy  								 
FallbackNTP=2.debian.pool.ntp.org 3.debian.pool.ntp.org #Servers listed should be In Accordence With Local Policy
--
RootDistanceMax=1 #should be In Accordence With Local Policy

Further investigation shows that the CIS Ubuntu Linux 18.04 LTS Benchmark v2.0.1
Remediation Procedure for 2.2.1.2 - Ensure systemd-timesyncd is configured has the CORRECT ✅ config key:

edit the file /etc/systemd/timesyncd.conf and add/modify the following lines in
accordance with local site policy

NTP=0.ubuntu.pool.ntp.org 1.ubuntu.pool.ntp.org 2.ubuntu.pool.ntp.org
FallbackNTP=ntp.ubuntu.com 3.ubuntu.pool.ntp.org
RootDistanceMaxSec=1

@micheelengronne the V2 controls were written to match the audits/remediations defined in the benchmark as exactly as possible, but this is obviously an error. Is there a preference on how to handle these type of discrepancies?

@yvespp would you mind sharing your process in discovering this bug? Curious if this was caught in some automated way which could have caught this earlier in the development cycle.

[yvespp]

@deric4 It was more by chance. I checked the timesyncd docs because I wanted to know more about the value and the copied it from the docs to our vm template. After that the test was still failing and then I filed this bug.

[micheelengronne]

@deric4 I don't know if the CIS Center has any kind of procedure to resolve that.

On the Devsec side, I would go for passing the problematic key as a parameter that would take RootDistanceMax as default but could be altered to RootDistanceMaxSec on a user basis.

That way, users who really need (for insurance reasons for instance) to be compliant with CIS Distribution Independent Linux Benchmark v2.0.0 would leave the parameter as it is and other users would be able to modify it.

[chris-rock]

I just double-checked the latest version DIL 2.0.0 pdf (it seems like this was altered but the version was not increased 🤷 ) It states the correct RootDistanceMaxSec in 2.2.1.4. My proposal is to put up a PR to fix the test without any additional attribute. In general we should follow the guidance of what makes sense. If the CLI example in CIS in wrong, we can just implement the control correctly.