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