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

Sat Mar 7 19:34:43 UTC 2009
Robert Heller <heller at deepsoft.com>

At Sat, 7 Mar 2009 10:45:19 -0500 (EST) CentOS mailing list <centos at centos.org> wrote:

> 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.

The problem is that the mkinitrd rpm that is shipped with CentOS 5.2
*go into an infinite loop* if one is installing a kernel on a system
with software raid disks.  This means that the base install process
*hangs*.  I suspect that killing the looping mkinitrd process kills
(crashes) the install.  This means it is impossible to do a base
install this way.  *This is a known problem* (check the bug database
for both RHEL5 and CentOS5 for details).

The only other option is to patch the mkinitrd script *while* the
install is in progress.  I ended up doing this when I originally
installed CentOS 5.2, but mis-typed the patch command and ended up with
a zero length file in /sbin/mkinitrd -- this did not cause the
installer to crash, it just failed to make the initrd file -- not
really a problem -- I just booted with a rescue disk and manually
re-made the initrd (and it was only a secondard O/S on my system and I
had told the installer to not install any boot loader).

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

Robert Heller             -- 978-544-6933
Deepwoods Software        -- Download the Model Railroad System
http://www.deepsoft.com/  -- Binaries for Linux and MS-Windows
heller at deepsoft.com       -- http://www.deepsoft.com/ModelRailroadSystem/