Our security team utilizes Tenable for vulnerability monitoring and reporting. For data collection we deploy Tenable’s Nessus Agent to our hosts. We’re noticing a large number of false positives being reported with Apache - I know we have the backported patches as I’ve verified that an rpm --changelog shows the reported CVEs as resolved, but it seems like they’re not being detected by Tenable. Does anyone else utilize a similar setup? Have you been able to get Tenable to recognize the backported patches on RL?
This works out of the box with RHEL, which is making me think it’s an issue with Tenable not recognizing Rocky as being RHEL-derived, but I haven’t been able to make much headway with them. I’m curious if anyone else has run into this problem.
It really depends on how the scanners are actually checking for these things. In my experience, scanners either look at the initial version and call it vulnerable (without considering backporting), or they look at the direct NEVRA of a package (e.g. from RHEL) and use that as the absolute baseline meaning if it doesn’t equal it entirely, you are considered vulnerable.
As an example of the above, look at Rocky Linux 8. The httpd package is httpd-2.4.37-56.module+el8.8.0+1284+07ef499e.6 while RHEL 8 is httpd-2.4.37-56.module+el8.8.0+18758+b3a9c8da.6. A scanner could look at the the Rocky package and say “yep that’s vulnerable” because it does not understand the nuance of dnf modularity.
It really depends on how these scanners are actually “scanning” for these things. It is not uncommon for it a scanner to say RHEL is fine but Rocky Linux is not.
A scanner like Tenable will have rules like “If this is RedHat and the package is 1.2.3.4 then assume patched”. They need to fix the rules to include Rocky within the “RedHat” definition.
Of course this is gonna get more complicated with RH’s recent changes; Rocky may end up being the only rebuild where Tenable can say this!
It is how module build service works. Their MBS started a long time ago, ours started only a couple years ago. 1284 means that it was the 1284th build. There were 1283 builds before it. Same goes for 18758 from Red Hat. We cannot arbitrarily increase the number or modify the dist tag.
No, it does not break the “compatible” rule. It is the same content.
Content is the same, but meta-data is different. Simply because the rpm name is different. Systems that depend on this meta-data (e.g, bad Nessus rules) will flag as a result.
I’m not saying “Rocky is broken”; I’m just pointing out a compatibility issue between Rocky and RHEL. It’s not the only one (eg contents of /etc/redhat-release). It highlights a limit to “bug compatible”.
It’s necessary for consumers of Rocky (and CentOS before this; it suffered the same problem) to understand these differences.
It’s not a compatibility issue between Rocky Linux and RHEL. Just because the dist tag happens to be slightly different (as a result of how MBS works), does not bring any sort of incompatibilities.
CentOS 8 did the same thing. CentOS Stream 8 and 9 are in the same boat (see here and here) where their build numbers are much lower than that of RHEL.
If a scanner is unable to parse through modular data or properly look at an RPM’s metadata to figure things out, that is on them.
I think we might be “violently agreeing” with each other.
A decade ago there were plenty of commercial application installers that looked at /etc/redhat-release and broke on CentOS because the contents were different. The “what is this OS” detection routine failed.
Today we have tooling that doesn’t properly understand rpm name formats.
Strictly, this is a compatibility problem, because an application that works on RHEL may fail on any rebuild (Rocky, CentOS, alma, whatever). It’s just one we understand and accept.
Well, when arguing this way (syntactically) then RHEL != RL, right? Its important to use some expertise to evaluate. The git hashes of RHEL are just representations, the git hashes of RL can’t be the same but they represent the same. So, module names are different but the 1:1 compat promise not. I hope the misconception of compatibility vanished now.