Bug 455693

I think Fedora would be a better place for this issue to be discussed.


+++ This bug was initially created as a clone of Bug #435033 +++

Description of problem:

The dependency on initrd is increasing with every release. With features like
SAN Boot, the OS is heavily dependent on a proper initrd.
Currently, we don't seem to be having a proper way of supporting initrd images
like we do for other packages (RPM signed packages or non-tainted kernels)
It is difficult, during root cause of problems reported by customers, to be sure
that they are running the recommended setup as instructed by the OS vendor. This
is very true because most 3rd party ISVs or applications modify/overwrite the
initrd generated under the OS Vendor's guidelines.

We need an infrastructure to track down the correct initrd being used to boot
the OS.

Version-Release number of selected component (if applicable):
All

How reproducible:
Always

Steps to Reproduce:
1. Tamper some behavior for the initrd.
2. Create the tampered initrd image by overwriting the original initrd image.
And
1. Boot into the OS.
2. There is no way to know what initrd image was used during boot.
  
Actual results:
There is no way to identify the authenticity of the initrd image. And there is
no way to identify what initrd image is used during boot.

Expected results:
We should have a signature based verification of the initrd image (Just like GPG
signed RPM packages). But how are we going to sign the image during installtime
creation is a problem.
And we also need a way to identify (on the basis of name) what initrd image is
used to boot. Something like /proc/cmdline

-- Additional comment from katzj on 2008-03-02 12:30 EST --
The problem is that every initrd image is different based on what the system
contains.  And there really isn't any way to do "verification" of it that
couldn't just have the same things done by a third party.

-- Additional comment from pm-rhel on 2008-03-02 12:46 EST --
Development Management has reviewed and declined this request.  You may appeal
this decision by reopening this request. 

-- Additional comment from rsarraf on 2008-05-11 04:38 EST --
Currently, on a freshly installed box, firstboot is executed on the very first 
boot. firstboot expects the user to configure the machine for RHN updates. Once
configured, the machine is covered under Red Hat's support programme.

If I'm correct, a customer calling Red Hat for support, if doesn't have his
machine subscribed to RHN, will have lesser chances for support.

With this understanding, let's try this:
We include functionality in Anaconda to generate a checksum of the initrd image
and send it to RHN during subscription. With this checksum in place, the user's
machine can now be tracked for a tampered/non-tampered initrd image.

But there still is one case:
The user wants to recreate the initrd image to add some additional functionality
provided natively by the OS. No 3rd party involvement still. In this case, a new
checksum will be seen for the genuine initrd image that needs to be supported.

Probably what we can do here is something like this:
* Taint the kernel if a kernel module _not_ provided by the OS vendor is loaded.
* Now add functionality in mkinitrd to warn the user that re-creating an initrd
image from a tainted kernel will void the support contract.
* If the kernel is not tainted, re-create the new initrd image and store its
checksum. If network connectivity is there, send it to RHN.

-- Additional comment from borgan on 2008-06-17 14:17 EST --
the concept is a good idea, but I'm not sure how the mechanism will function ...
a few concerns:

1) not all arches guarantee that firstboot will run (s390x, for example), so a
solution that is dependent upon firstboot is not valid for those situations

2) tainting has a specific expectation in the kernel space, namely used for
noting the presence of non-open source modules in a running kernel;  to have the
kernel "taint" just because the initrd is not generated by the installer would
change that behaviour and expectations and probably not be well received

some things mentioned do seem to have possibilities:

* generating a unique checksum or signature of the initrd 
* present/log the signature of the initrd to the console sometime during bootup

but there may still be open concerns with them ...