Ross S. W. Walker wrote: > The agencies don't know what security backports vendor XYZ > has implemented and frankly they don't care. All they have > is a list of minimum version numbers that software must be > at in order for it to be deemed "compliant". So check the actual version number of the package. Using a remote network software scanner to detect security problems based on banner strings provided by the network software is nothing more than a false sense of security. > I think we will start seeing this in the PCI and HIPA > compliance regulations first, but I wouldn't be surprised > if it leaks out into GLBA and other regulations over time. The scanning vendors will be forced to fix their products. It's perfectly acceptable, and preferred behavior to backport patches. Just look at the recent Samba thread here for a good reason why backporting is good. I'd be mightily pissed if RHEL or CentOS switched a version out from under me which caused breakage. I honestly cannot believe that RHEL did that for Samba. If anything introduce a new ALTERNATE package that has the incompatible changes in it and allow users to choose between that one and the original for their systems. That's just me though. Fortunately I don't really use Samba. > I think it will be these compliance issues that may force > upstream to change their strategy otherwise I can see this > being a roadblock to RHEL/CentOS adoption in these > industries in the future. I highly doubt it. It'll be the scanning companies that will have to change. RHEL/CentOS are not the only ones that backport fixes. Really they need to have a database of package names and versions, and a set of scripts to run on the various servers to compare the versions with their "approved" list. After all it's not easy to remotely determine the kernel version. Network scanning is OK for some things, especially if you are attempting the actual security vulnerability rather than just assuming it has or does not have it based on the version. Take Oracle for example, pretty expensive piece of software. Lots of security holes in it. I'm not a DBA so I looked up how to find what patches are installed, and as far as I can tell you cannot determine those patches remotely, you need to run a command on the local host. My production oracle servers(10.2.0.3) currently have 34 patches installed. And the version string did not change. Installed Top-level Products (3): Oracle Database 10g 10.2.0.1.0 Oracle Database 10g Release 2 Patch Set 1 10.2.0.2.0 Oracle Database 10g Release 2 Patch Set 2 10.2.0.3.0 There are 3 products installed in this Oracle Home. Interim patches (34) : [..] (snip) And guess what? all 34 patches are security related. I have 8 more patches to get installed soon as well. nate