At Sat, 7 Mar 2009 10:45:19 -0500 (EST) CentOS mailing list centos@centos.org wrote:
On Sat, 7 Mar 2009, Robert Heller wrote:
At Fri, 06 Mar 2009 23:31:08 +0100 CentOS mailing list centos@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@centos.org http://lists.centos.org/mailman/listinfo/centos