os_ssh_fips_compliant Failing

[johnsonea2NIH]

We are currently using the mSCP to configure our security baseline for our Jamf pro instance. We have been failing the os_ssh_fips_compliant check. We have Silicon M1 macs running macOS 13 that were released in 2021. According to https://support.apple.com/guide/certifications/macos-security-certifications-apc35eb3dc4fa/web
Our current and future mac fleet will not be validated against FIPS 140-2, instead will be FIPS 140-3 due to our current baseline OS (macOS Ventura) and hardware specs (Apple Silicon, M1….future M2)

Summary of current certification status
macOS 13 Ventura user space, kernel space, and secure key store are undergoing laboratory testing. They are listed on the Implementation Under Test List and, when testing is complete, on the Modules in Process List.
macOS 12 Monterey user space, kernel space, and secure key store are undergoing laboratory testing. They are listed on the Implementation Under Test List and, when testing is complete, on the Modules in Process List.
macOS 11 Big Sur user space, kernel space, and secure key store have completed laboratory testing and have been recommended by the laboratory to the CMVP for validation. They are listed on the Modules in Process List.
The table below shows the Apple cryptographic modules that are currently being tested by a laboratory, that have been recommended by a laboratory for validation by the CMVP, or that have been validated and certified as conformant to FIPS 140-3 by the CMVP.

How are others with newer hardware and running newer os passing this check?

Any help is greatly appreciated!!

[robertgendler]

FIPS is a complicated thing.

You'd have to post more on how the check is failing the os_ssh_fips_compliant. But actual fips compliance validation has nothing to do with that.

You can be strict FIPS compliant to a tee or you can be up to date and secured. You cannot be both due to the backlogs of in the validation system. Most CISOS will understand this and grant waivers, especially for a company like Apple or Microsoft who have a history going back a decade of getting FIPS validation.

[johnsonea2NIH]

Thank you for the reply!

The check for this control is:

fips_sshd_config=("Ciphers aes128-gcm@openssh.com" "HostbasedAcceptedAlgorithms ecdsa-sha2-nistp256,ecdsa-sha2-nistp256-cert-v01@openssh.com" "HostKeyAlgorithms ecdsa-sha2-nistp256,ecdsa-sha2-nistp256-cert-v01@openssh.com" "KexAlgorithms ecdh-sha2-nistp256" "MACs hmac-sha2-256" "PubkeyAcceptedAlgorithms ecdsa-sha2-nistp256,ecdsa-sha2-nistp256-cert-v01@openssh.com" "CASignatureAlgorithms ecdsa-sha2-nistp256")
total=0
for config in $fips_sshd_config; do
total=$(expr $(/usr/sbin/sshd -T | /usr/bin/grep -i -c "$config") + $total)
done

echo $total

Expected value is 7. We are returning a value of 0.

[robertgendler]

There's a few things happening, running the check not in root context will fail because sshd -T requires root.

No hostkeys is due to never using sshd.

I suggest building the compliance script and checking that way as we have logic within the script to deal with all of this.

[SkydiveMike]

I had something similar(*), the core of the failure is that when/if sshd -T fails with an error code it does not pass data through the pipe to grep -c so that the count never works.

This one is tricky … I have time to work on it in my environment over the rest of the week, if I can improve the check, I'll post it or submit a PR.

(*) A mismatch between a different configuration I had set, nothing to do specifically with this project, except in my case it caused sshd -T to exit with an error code.