[CentOS-devel] yum-plugin-security and shellshock

Wed Oct 1 10:03:11 UTC 2014

Thanks Johnny for taking the time, it looks like the issue is much more convoluted than I initially assumed.

Lucian

--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro

----- Original Message -----
> From: "Johnny Hughes" <johnny at centos.org>
> To: centos-devel at centos.org
> Sent: Wednesday, 1 October, 2014 10:00:04
> Subject: Re: [CentOS-devel] yum-plugin-security and shellshock

> On 09/30/2014 11:10 AM, Kevin Stange wrote:
>> On 09/30/2014 10:03 AM, Nux! wrote:
>>> What needs to happen for that?
>> 
>> We had a short discussion about it here:
>> 
>> http://lists.centos.org/pipermail/centos-devel/2014-September/011893.html
>> 
>> The issue is that something during the issuance of new updates has to
>> build a persistent list of CExAs and then regenerate the updateinfo.xml
>> while building the repo update.
>> 
>> Right now CentOS pushes the update notices directly to the mailing list
>> and doesn't store that data anywhere to generate the XML file.  The only
>> way I know to build historical updateinfo.xml would be to scrape the
>> mailing list for all previous data.  Needed are release ID, package
>> (name, version, release, arch), SHA sum, release type (bug, enhancement,
>> new package, security), severity (if security), reference URL, summary,
>> additional description (if any).
>> 
>> SL publishes updateinfo.xml so if someone has insight into how they
>> manage it, perhaps we could make use of the process to shoehorn into
>> CentOS. See:
>> 
>> http://ftp.scientificlinux.org/linux/fermi/scientific/6x/x86_64/updates/security/repodata/updateinfo.xml
>> 
> 
> I think that is only one issue.
> 
> The other issue (as I understand it), is that we would need an all
> encompassing metadata across all versions to make this work as well.
> 
> Meaning that (lets take CentOS-6 as an example) ... we would need a tree
> of all RPMs (6.0, 6.1, 6.2, 6.3, 6.4, 6.5 .. plus all the updates
> directories) on all the mirrors to make that work.
> 
> I suppose we could do it if all the metadata was in one place (at a
> level up) and the directories could be separate.
> 
> But either way, it would add significantly to the size required to
> mirror CentOS and require a redesign of how we do trees completely (we
> currently only push the latest tree for each live major version).
> 
> (For example, we would likely have to separate ISOs out of main trees as
> there is no way we could mirror all the ISO's as well as all the binary
> RPMs for 11 CentOS 5 versions, 5 CentOS 6 versions, etc. to every
> mirror, that is several TB of info if we include ISOs)
> 
> =====================================================================
> 
> So, all of this would be required and the end result would be that you
> would then be able to install security updates only.
> 
> The only problem with that is ... in a staged build system, security
> updates only is not supported.  It is not really supported in RHEL
> either.  Why do I say that?  Look at any RHEL RHSA update .. I'll take
> one of the shellshock updates:
> 
> https://rhn.redhat.com/errata/RHSA-2014-1306.html
> 
> If you look at the Solution section you will see this quote:
> 
> "Before applying this update, make sure all previously released errata
> relevant to your system have been applied."
> 
> It does not say all "previously release Security Errata" has been
> applied ... it does not say all "BugFix and Security Errata" has been
> applied .. it says "all previously released Errata" has been applied.
> 
> Why is that?
> 
> Well, because things are built on top of the last update (the build root
> used is 'staged').  The build root grows as you add packages to the
> distribution.  Package A is built, it goes into the build root and then
> Package B gets built the next day against that Package A.  If you run
> that Package B against an older version of Package A than the one it was
> built against, then it may not work the same way as it was intended to work.
> 
> So, the only 'supported' and 'tested' configuration is all the latest
> packages installed.
> 
> That is why Red Hat specifically has EUS/AUS repositories where they
> SPECIFICALLY built the same bash (in our example) against the extended
> 6.4 EUS tree.  They have a different shell shock patched build of bash
> there:
> 
> https://rhn.redhat.com/errata/RHSA-2014-1311.html
> 
> The bash for RHEL-6.4 AUS is (after being built against the 6.4 AUS
> tree) different that the one for RHEL-6.5 .. why is that?  Because it is
> the same source code, but it is built against a different subset of
> packages.  (The AUS is basically all of 6.4 as it was when 6.5 was
> released, and all the new 6.5 security updates, built in order and in a
> staged manner against that 6.4 tree ... so it is '6.4 plus 6.5 security
> updates'.) Do you think Red Hat would maintain a separate AUS/EUS 6.4
> tree and build all the new security updates from 6.5 again against that
> 6.4 EUS/AUS tree if the users could just not update to 6.5 and just use
> yum-security to use the 6.5 updates?  Of course not, they would just use
> the 6.5 security packages for 6.4. They don't use the 6.5 security
> updates directly against 6.4, because it might not work.  Instead, they
> maintain a separate 6.4 tree.
> 
> If you take the 6.5 bash update and install it in 6.4, will it work?
> Likely.  Will it absolutely fix the security issue?  Maybe not .. it is
> certainly not 'supported' by Red Hat that way.
> 
> ======================================================================
> 
> So, only installing Security updates and not all updates is not a very
> good idea (certainly on on different minor versions), because you are
> not operating in a tested manner and the update could very well not even
> mitigate the security issue UNLESS you install all updates (security and
> otherwise) that happen before it anyway.
> 
> Therefore why would we want to take great pains to totally redesign our
> mirror infrastructure (the size increase rendering some number of our
> current donated mirrors as too small to now be used).  Take great pains
> to maintain a separate database of Security info to generate the xml
> file.  Then that will make the end release that it is now very easy for
> users to think they are safe (because they do all security updates after
> all) ... but they are not safe because they are running 6.5 security
> updates against 6.4?  Or help them run only critical security updates
> and the combination introduces new issues unique to that combination?
> 
> They only way to have another secure combination is to build and test
> the security updates in that combination.  If you want 6.3 with only the
> 6.4 and 6.5 Moderate Security updates (or above) added to that, you
> would need to build the 6.4 and 6.5 security updates (in order) against
> that 6.3 tree ... staging it as you go so that the next update gets
> built against the update before it.  You would also then need to TEST
> that this combination actually fixes the security issues.  Then you
> could be reasonably sure that the solution was safe.
> 
> But if you just installed the CentOS 6.4 and 6.5 moderate updates (or
> higher) on CentOS 6.3 (the same packages you rebuilt in the preceding
> paragraph) .. even if they installed, it would be significantly
> different than the solution where you built them yourself.
> 
> 
> 
> 
> _______________________________________________
> CentOS-devel mailing list
> CentOS-devel at centos.org
> http://lists.centos.org/mailman/listinfo/centos-devel