[CentOS] Creating an alternitive install CD for CentOS 5.2 (w/ patched mkinitrd)

Sat Mar 7 15:45:19 UTC 2009
R P Herrold <herrold at centos.org>

On Sat, 7 Mar 2009, Robert Heller wrote:

> At Fri, 06 Mar 2009 23:31:08 +0100 CentOS mailing list <centos at centos.org> wrote:

>>> I am also not sure if I need to update any of the files the installer
>>> uses to install the system -- is it enough to just drop the alternitive
>>> mkinitrd rpm?  Do I need to rebuild any of the other files on the CD?

> This seems overly complex for my needs.  I don't want (or need) to
> rebuild all 6 of the install CDs.  I just want to *replace* one RPM on
> the first CD.

This is the problem with people thinking a respin is just 
shuttling files in and out, or adding a driver to a mkinitrd.

In a post process, you can easily enough 'update' the one RPM 
in question with a bit of care in choosing the EVR 
information.  Anaconda has provided for this in every CentOS 
release, and it usually suffices (adding install time drivers 
are the major exception).  One can drop in anything that may 
be scripted -- the environment can be made Turing complete.


But then, _who_ is on the hook for maintaining and supporting 
such a respin?  No intention for providing a yum archive for 
updates is stated; no attention is paid to ensure that 
'authentic' SIGNED rpms would be retrieved.  Who gets splashed 
with mud when things go wrong?


Assume there turns out to be a security hole in that package 
and it needs to be updated, or even worse worse if the 
re-spinner adds a package to drop in a "no key  required" 
'just a couple of files add-on' updates yum archive.

For the sake of analysis assume that the archive added then 
gets compromised.  Or the re-spinner loses interest, and lets 
the domain lapse, and it gets picked up by a 'blackhat'.  Or a 
DNS poisoning attack subverts resolution of the domain -- no 
signed package protection can raise the alarm.  It was 
bypassed.

As I say, the customary bypass I have seen by minimal interest 
'just change a couple of things' packagers and archives, is to 
wholly disable key checking for the archive they add.  People 
regularly offer content from their personal archives. [I 
invite a self-audit, and would welcome a report of the last 
ten mentioned, to see if they are still viable (churning out 
updates), offering ONLY signed content with a well published 
signing key fingerprint, and issuing a yum.repo.d file 
requiring the packages used to be signed.]

So continuing the thought experiment, when so altered to 
trust an additional archive, the remote machines doing update 
through cron, or yum-updatesd will trust ANYTHING, including 
malicious content, placed in that compromised archive.

Game over.

Here is the fallout: The poor end user 'knows' it was CentOS, 
because she was told by the respinner that it is 'CentOS with 
just one package replaced'.  Who gets the black eye here? 
Who bears the support load of sorting out what happened when 
the poor hurt user shows up in what she thinks is the correct 
support venue, barely able to describe her VOIP turnkey box's 
operation?

The answer is, of course, the main mother-ship CentOS project 
folks.

And it is not right that people do this to us, but it is also 
hard to stop.  Probably the only real solution is to enforce 
the CentOS trademark on the art and brand packages, and 
prohibit respins containing such (just as the upstream does).

Sad, but true.

There is a reason the core CentOS group are skittish about 
respins.  We'll have to discuss this seriously.

-- Russ herrold