Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 455693 - How do we support and authenticate initrd images
Summary: How do we support and authenticate initrd images
Keywords:
Status: CLOSED CANTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: anaconda
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Anaconda Maintenance Team
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: 435033
TreeView+ depends on / blocked
 
Reported: 2008-07-17 06:42 UTC by Ritesh Raj Sarraf
Modified: 2009-06-05 21:32 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-06-05 21:32:26 UTC


Attachments (Terms of Use)

Description Ritesh Raj Sarraf 2008-07-17 06:42:03 UTC
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@redhat.com 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@redhat.com 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@netapp.com 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@redhat.com 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 ...

Comment 1 Chris Lumens 2009-06-05 21:32:26 UTC
This is best discussed in the context of dracut, which is the project to replace mkinitrd and revamp all our initrd infrastructure.  Unfortunately, there's no component in bugzilla here to assign this bug to.  dracut's site appears to be at:

http://apps.sourceforge.net/trac/dracut/wiki

There's mailing lists and everything there.  I invite you guys to move this discussion there so it can get more attention.  I can't think of a proper resolution for this so I'm going to close it as CANTFIX, but it can easily be dealt with if dracut chooses to implement it.


Note You need to log in before you can comment on or make changes to this bug.