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