Bug 435033

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.

Development Management has reviewed and declined this request.  You may appeal
this decision by reopening this request. 

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.

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

Reopening to keep on the RHEL 6.0 list assuming the Fedora bug gets integrated.

Bug 455693 created for Fedora.

Will a MAC policy help us here?
IIRC SELinux is at the syscall level but can that be used?

Something like an SELinux rule which'd say, "Only allow modifications of initrd images from the RPM command".
This way we only let initrd to be modified/updated with authentic Red Hat kernel rpm packages.
There still will be ways for people to overcome this (temporarily setenforcing), but then the user knows what he/she is doing.

We don't normally confine the root user, which is what would be required here.

Above mentioned kind of problems must be the ones why tytso came up with the idea of Tainting the kernel from Userspace.
We would not want to spend time debugging, when the user did unacceptable things with her OS installation. (Here initrd being the example).

Let me try another minimalistic approach :-)

In the kernel RPM package, during post installation we could generate the checksum:

%define kernel_variant_post(v:r:) \
%{expand:%%kernel_devel_post %{?-v*}}\
%{expand:%%kernel_variant_posttrans %{?-v*}}\
%{expand:%%post %{?-v*}}\
%{-r:\
if [ `uname -i` == "x86_64" -o `uname -i` == "i386" ] &&\
   [ -f /etc/sysconfig/kernel ]; then\
  /bin/sed -r -i -e 's/^DEFAULTKERNEL=%{-r*}$/DEFAULTKERNEL=kernel%{?-v:-%{-v*}}/' /etc/sysconfig/kernel || exit $?\
fi}\
/sbin/new-kernel-pkg --package kernel%{?-v:-%{-v*}} --mkinitrd --depmod --install %{KVERREL}%{?-v:.%{-v*}} || exit $?\

# Proposed approach
/sbin/gen-checksum initrd > /boot/%{KVERREL}%{?-v:.%{-v*}}.initrd.checksum


We add the checksum to /boot or where ever appropriate (inside the initrd image ?).
During boot, the initrc script in the initrd could do the checksum check of the initrd image.
And if the checksum of the initrd image, that we are booting from, doesn't tally with the checksum that was generated during kernel installation, we *Taint the kernel from Userspace*.
That's all.

Are there other official Red Hat tools that are allowed to mangle with the initrd image ? If yes, they also need fall under a similar policy


Now, in our debugging logs, if we see "Tainted U", we know that the user possibly did something nasty or non-standard.

Do you guys think this approach could help improve the current "Initrd Dependency" flux?
I can come up with a patch if this looks good.

Something like this *definitely* needs to be in Fedora first before it even gets a whiff of RHEL. Moving to Fedora.

(In reply to comment #17)
> Something like this *definitely* needs to be in Fedora first before it even
> gets a whiff of RHEL. Moving to Fedora.

You might want to pull Dave Jones in to get some feedback. He currently is working on a proposal to have a unified initrd solution across distributions.

Details can be tracked here:
https://fedoraproject.org/wiki/Initrdrewrite

This is a mass edit of all mkinitrd bugs.

Thanks for taking the time to file this bug report (and/or commenting on it).

As you may have heard in Fedora 12 mkinitrd has been replaced by dracut. In Fedora 12 the mkinitrd package is still around as some programs depend on
certain libraries it provides, but mkinitrd itself is no longer used.

In Fedora 13 mkinitrd will be removed completely. This means that all work
on initrd has stopped.

Rather then keeping mkinitrd bugs open and giving false hope they might get fixed we are mass closing them, so as to clearly communicate that no more work will be done on mkinitrd. We apologize for any inconvenience this may cause. 

If you are using Fedora 11 and are experiencing a mkinitrd bug you cannot work around, please upgrade to Fedora 12. If you experience problems with the initrd in Fedora 12, please file a bug against dracut.