[CentOS] CentOS 5 Security Updates

Thu Feb 24 20:21:18 UTC 2011
Cal Webster <cwebster at ec.rr.com>

On Thu, 2011-02-24 at 14:28 -0500, R P Herrold wrote:
> On Thu, 24 Feb 2011, Cal Webster wrote:
> 
> > java-1.6.0-sun
> 
> non FOSS, non-source provided, no?  This is in an addon 
> channel in RHEL, and so far as I know we have never shipped 
> such

You're right - shouldn't have listed that one. I manage both RHEL and
CentOS machines so this came up on the radar.

> Of the others the wireshark update is a periodic update of 
> some edge case dissectors [these developers are quite good 
> about releasing time based 'fixes' for their tool -- a 
> different model than upstream, but perfectly valid], and if 
> nominally remotely exploitable, as a practical matter, not a 
> material threat

Agreed. We don't use most of the dissectors that get called out either
and it's easy to disable them. However, our organizational directives
require full IA compliance so I have to show due diligence in resolving
every vulnerability. For those that cannot be resolved I must supply
work-arounds to mitigate them and a plan of action to resolve it in the
end.

> The kerberos update crossed vendor-sec, but seems again to be 
> an edge case hole

Not critical for us since none of our engineering networks touch the
Internet. If I had a public facing server, though, I'd hate to have to
wonder if I might be one of those "edge cases".

> The pgsql update is nominally exploitable, but any sensible 
> environment uses iptables and network segment isolation rather 
> than adding a world listening daemon

True. Any enterprise operation that doesn't take such basic security
precautions is asking for trouble. Still, the IA Gestapo doesn't make
such distinctions.

> I have commented earlier on my distress at the openjdk 
> update NOT crossing vendor-sec.  This said, again, who in 
> their right mind exposes an unprotected Java listener 
> application to the wild?

I don't disagree with you. Those who evaluate CVE's for applicability to
an enterprise don't often have the technical background to distinguish
between a practical and theoretical threat. For them, and because of the
way $#!+ rolls downhill, myself the vulnerability "must be addressed."

> I saw that another in the project mentioned 'bypassing' the 
> 5.6 respin and testing delays for truly exploitable matter. 
> The potential 'bind' updates dos attack vector turned out not 
> to affect anything CentOS has shipped in base and updates, and 
> so was a 'false positive' as prior discusseio here has noted
> 
> If one wants SLA and deterministic intervals between 
> announcement and release, it is just not that hard to set up 
> one off building and updates from released sources upstream, 
> and so one can have it at the price of a little learning and 
> experimentation.

When things settle a bit in my org and CentOS I'd like to do just that,
if for nothing else than the instructional value.

> Alternatively, CentOS releases promptly on the usual norm, and 
> during 'point' update times, falls back to trying to avoid 
> 'dependency skew' problems by considering the potential 
> disruption for millions of machines each needing manual 
> depsolving intervention, vs. getting the nest update build and 
> QA's and out the door in a durable fashion.

Until this 3-way, back-to-back release (4.9, 5.6, 6.0) updates were
plenty prompt for me. I totally understand the issues behind the delays.

> If that is not 'quick enough', see the prior paragraph about 
> self-building; or seek a vendor who will sell you the SLA you 
> deem you require.  This is a simple 'build vs buy' decision

Thank you for your cordial, detailed reply. We do have a standby OSS
support contract based on hourly rate but only intend to use it for true
emergencies. 

> [I might note that I have seen NO filed bug in the CentOS 
> tracker asserting a need for any of the listed updates on an 
> expedited basis]

Is that how it's done? Until now I haven't paid much attention to the
process. No need since updates were fairly swift after upstream release.
I report bugs directly upstream via our RH Support entitlement. I'm not
sure any such assertions from me would carry much weight anyway. Even if
they did I'd imagine there wouldn't be much spare manpower to act on it
at this point.

> -- Russ herrold
> _______________________________________________
> CentOS mailing list
> CentOS at centos.org
> http://lists.centos.org/mailman/listinfo/centos