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
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
