The company I work for provides Linux-oriented consulting services for a lot of security-focussed organizations. We generally start with compliance-content from the Compliance as Code project (and have done so since at least EL7). This has worked for us for RHEL, CentOS, OEL and, since the CentOS to CentOS-Stream nonsense, Alma Linux 9. Unfortunately, there doesn’t appear to be any Rocky-related content in that project, yet. Is Rocky planning to contribute profiles for Rocky to that project? Right now, the lack of Rocky content in Compliance as Code is a major sticking point for our customers and something that pushes them towards Alma in its stead (when they might otherwise have selected Rocky).
What’s the problem exactly? As far as I can see, I can do this on Rocky:
dnf install scap-security-guide
It says even how to install it in the README.md within that project.
And then I can do all the scans I need to ensure it’s compliant. For example:
root@rocky9:~# oscap xccdf eval --profile xccdf_org.ssgproject.content_profile_ospp --results-arf arf.xml --report report.html --oval-results /usr/share/xml/scap/ssg/content/ssg-rl9-ds.xml
as you can see, it’s clearly using a Rocky Linux profile. Therefore I don’t see what the problem is? The fact I can actually install the packages mentioned in the README.md within that project, and also find a security profile as shown in my example command above, and scan my system to verify it adheres to compliance means there isn’t a problem.
We can also check the content within that package I installed:
root@rocky9:~# rpm -ql scap-security-guide
/usr/share/doc/scap-security-guide/LICENSE
/usr/share/man/man8/scap-security-guide.8.gz
/usr/share/scap-security-guide/ansible/rhel9-playbook-anssi_bp28_enhanced.yml
/usr/share/scap-security-guide/ansible/rhel9-playbook-anssi_bp28_high.yml
/usr/share/scap-security-guide/ansible/rhel9-playbook-anssi_bp28_intermediary.yml
/usr/share/scap-security-guide/ansible/rhel9-playbook-anssi_bp28_minimal.yml
/usr/share/scap-security-guide/ansible/rhel9-playbook-ccn_advanced.yml
/usr/share/scap-security-guide/ansible/rhel9-playbook-ccn_basic.yml
/usr/share/scap-security-guide/ansible/rhel9-playbook-ccn_intermediate.yml
/usr/share/scap-security-guide/ansible/rhel9-playbook-cis.yml
/usr/share/scap-security-guide/ansible/rhel9-playbook-cis_server_l1.yml
/usr/share/scap-security-guide/ansible/rhel9-playbook-cis_workstation_l1.yml
/usr/share/scap-security-guide/ansible/rhel9-playbook-cis_workstation_l2.yml
/usr/share/scap-security-guide/ansible/rhel9-playbook-cui.yml
/usr/share/scap-security-guide/ansible/rhel9-playbook-e8.yml
/usr/share/scap-security-guide/ansible/rhel9-playbook-hipaa.yml
/usr/share/scap-security-guide/ansible/rhel9-playbook-ism_o.yml
/usr/share/scap-security-guide/ansible/rhel9-playbook-ospp.yml
/usr/share/scap-security-guide/ansible/rhel9-playbook-pci-dss.yml
/usr/share/scap-security-guide/ansible/rhel9-playbook-stig.yml
/usr/share/scap-security-guide/ansible/rhel9-playbook-stig_gui.yml
/usr/share/scap-security-guide/ansible/rl9-playbook-anssi_bp28_enhanced.yml
/usr/share/scap-security-guide/ansible/rl9-playbook-anssi_bp28_high.yml
/usr/share/scap-security-guide/ansible/rl9-playbook-anssi_bp28_intermediary.yml
/usr/share/scap-security-guide/ansible/rl9-playbook-anssi_bp28_minimal.yml
/usr/share/scap-security-guide/ansible/rl9-playbook-ccn_advanced.yml
/usr/share/scap-security-guide/ansible/rl9-playbook-ccn_basic.yml
/usr/share/scap-security-guide/ansible/rl9-playbook-ccn_intermediate.yml
/usr/share/scap-security-guide/ansible/rl9-playbook-cis.yml
/usr/share/scap-security-guide/ansible/rl9-playbook-cis_server_l1.yml
/usr/share/scap-security-guide/ansible/rl9-playbook-cis_workstation_l1.yml
/usr/share/scap-security-guide/ansible/rl9-playbook-cis_workstation_l2.yml
/usr/share/scap-security-guide/ansible/rl9-playbook-cui.yml
/usr/share/scap-security-guide/ansible/rl9-playbook-e8.yml
/usr/share/scap-security-guide/ansible/rl9-playbook-hipaa.yml
/usr/share/scap-security-guide/ansible/rl9-playbook-ism_o.yml
/usr/share/scap-security-guide/ansible/rl9-playbook-ospp.yml
/usr/share/scap-security-guide/ansible/rl9-playbook-pci-dss.yml
/usr/share/scap-security-guide/ansible/rl9-playbook-stig.yml
/usr/share/scap-security-guide/ansible/rl9-playbook-stig_gui.yml
/usr/share/scap-security-guide/kickstart
/usr/share/scap-security-guide/kickstart/ssg-rhel9-anssi_bp28_enhanced-ks.cfg
/usr/share/scap-security-guide/kickstart/ssg-rhel9-anssi_bp28_high-ks.cfg
/usr/share/scap-security-guide/kickstart/ssg-rhel9-anssi_bp28_intermediary-ks.cfg
/usr/share/scap-security-guide/kickstart/ssg-rhel9-anssi_bp28_minimal-ks.cfg
/usr/share/scap-security-guide/kickstart/ssg-rhel9-ccn_advanced-ks.cfg
/usr/share/scap-security-guide/kickstart/ssg-rhel9-ccn_basic-ks.cfg
/usr/share/scap-security-guide/kickstart/ssg-rhel9-ccn_intermediate-ks.cfg
/usr/share/scap-security-guide/kickstart/ssg-rhel9-cis-ks.cfg
/usr/share/scap-security-guide/kickstart/ssg-rhel9-cis_server_l1-ks.cfg
/usr/share/scap-security-guide/kickstart/ssg-rhel9-cis_workstation_l1-ks.cfg
/usr/share/scap-security-guide/kickstart/ssg-rhel9-cis_workstation_l2-ks.cfg
/usr/share/scap-security-guide/kickstart/ssg-rhel9-cui-ks.cfg
/usr/share/scap-security-guide/kickstart/ssg-rhel9-e8-ks.cfg
/usr/share/scap-security-guide/kickstart/ssg-rhel9-hipaa-ks.cfg
/usr/share/scap-security-guide/kickstart/ssg-rhel9-ism_o-ks.cfg
/usr/share/scap-security-guide/kickstart/ssg-rhel9-ospp-ks.cfg
/usr/share/scap-security-guide/kickstart/ssg-rhel9-pci-dss-ks.cfg
/usr/share/scap-security-guide/kickstart/ssg-rhel9-stig-ks.cfg
/usr/share/scap-security-guide/kickstart/ssg-rhel9-stig_gui-ks.cfg
/usr/share/xml/scap/ssg/content
/usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xml
/usr/share/xml/scap/ssg/content/ssg-rl9-ds.xml
of which you can see, there is exactly the same type of content and possibilities like RHEL9 has. Therefore there aren’t any deficiencies here.
That’s fine if you’re using a vendored process for doing scans and remediations. However, if you’re not (e.g., you’re using something like Tenable’s Nessus or similar external tooling), then “just use the RPM” isn’t an answer.
It’s interesting that you use the phrasing:
there is exactly the same type of content and possibilities like RHEL9 has
As it contributes to the overall impression that the Rocky’s ssg-rl9-ds.xml is just the rhel9 one with “we did a global-search-and-replace on the CPEs in the RHEL-originated files”.
Lack of content that’s been explicitly certified by/through benchmarking organizations (CIS, DISA, etc.) for a given platform means that organizations that care about those organizations’ “blessings” are going to nope-out on a distribution that hasn’t exerted a similar level of effort. That’s why Oracle bothered to create and get their RHEL-clone’s content certified (as is TuxWare for Alma and even Canonical has for Ubuntu). That leaves Rocky fine for casual users, but not for organizations that need to be able to point to a certifying organization’s “blessed” content.
And can you explain what the problem with that is, if that is the case? You do realise that Rocky9 is exactly identical to RHEL9? In which case, a global replace to recognise the distribution is Rocky 9 and not RHEL9 isn’t a problem.
You do also know that Alma is no longer identical to RHEL9 and therefore they have to make their own content because their package versions and content are somewhere outside of RHEL9 and probably more in alignment with CentOS Stream or wherever they cherrypick the packages from. Alma aim to be binary compatible, whereas Rocky is 1:1 the same as RHEL. Therefore I fail to understand the problem here when the only difference between Rocky and RHEL is effectively the name, that a global replace suffices since package versions are the same as RHEL?
The profile scans the system, and shows you where it is compliant and where it is not? What more do you want? Maybe you would like to join the Rocky community and create those additional profiles?
Also note, Nessus does have profiles itself for scanning against Rocky Linux. Tenable included those themselves… Rocky Linux Local Security Checks Plugins<!-- --> | Tenable®
I personally have no skin in the game with respect to Rocky’s adoption. I just know the reasons the customers I’ve worked with have opted for OEL or Alma as their alternatives to RHEL. I’m just relating the reality that I’ve encountered (and what it’d take to make Rocky a potential pick for them).
I think if you’re only looking at the Compliance As Code github repository then it’s a little short-sighted.
Nessus has official support for scanning Rocky, so does Rapid7’s products as well. I’m sure I could find more vulnerability scanners that support scanning Rocky Linux, and ensuring it’s compliant.
The packages that I mentioned that are included in the distribution are based on the same content from the Compliance As code repository that you linked. As also mentioned on that repository it’s recommended to install the packages from the distribution (as I quoted from their readme). And scans being made by that can be done successfully to ensure compliance.
Therefore, there is no reason not to choose Rocky. If they decided to choose something else, then that is up to them. But either way, based on evidence there isn’t any problem with not adhering to compliance.
The problem is that it’s not officially ours and there is no backing certifications. It is simply a piggyback of content that RHEL is certified for. CentOS is marked as a derivative also, so they get the same exact content despite zero certification. This is something that I (as release engineering lead) want to avoid sometime in the future.
We do not perform any copy-and-paste, see here. I suppose technically it is copy and paste, but it’s simply using the RHEL derivative functions that allow us to patch in pretty easily in our own packages, so the build will copy the content as needed into the rl9 XML files. I do understand that this works for users who use the packages directly but it does not help for those who need to use the upstream content.
Note that I agree with @ferricoxide that having just the content in our own repositories is not always enough. And doing the above patch helps some people in certain situations, but as we do not exist upstream officially, it can be problematic.
Having content in the Compliance as Code repository is something that I have brought up to our internal security team. I personally (as the release engineering lead) want us to have content there. The content we provide in our packages simply make us a derivative of the RHEL content, just like CentOS. CentOS is technically a derivative (despite it being upstream of RHEL now) when you use the content. For this project, I don’t want us to be a derivative any longer.
What I’ve brought up to the security team and my own team is that I want us to have our own content there for these (only in my view) reasons:
- In my opinion, it’s time to spread our wings and be a bit more serious in this area - We have enough users out there and despite being very identical to RHEL having our own content is likely the way to go now.
- We can actually get certifications from certain areas and not piggyback on what RHEL has to offer
The only problems I foresee doing this is it might take a long, long time to get certifications for specific compliances. It will be easy for us to put in CIS benchmarks, but for others, it will take time to continue to fill that in. This may (or may not) cause some confusion to you and others who use this content directly and to the users who use the package scap-security-guide regularly, especially since some are used to having every selectable item that RHEL has to offer as we patch ourselves in as a derivative currently.
With all that said, I’ve opened the discussion internally with the security team and my own team to begin research on this specifically. I don’t know where it’s going to go yet. To be honest, I have too many things on my plate personally to handle some of this, which is why I’ve asked @atomicturtle and @skip77 (who has shown interest in this on my team) to work on it and see where it goes.
1 Like