Bug 435033 - [NetApp F11 feat] How do we support and authenticate initrd images
[NetApp F11 feat] How do we support and authenticate initrd images
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: mkinitrd (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Peter Jones
Fedora Extras Quality Assurance
: FutureFeature, OtherQA, Reopened
Depends On: 455693
Blocks: 217209 554559
  Show dependency treegraph
 
Reported: 2008-02-26 17:33 EST by Ritesh Raj Sarraf
Modified: 2010-01-12 10:32 EST (History)
10 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-01-12 10:32:37 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Ritesh Raj Sarraf 2008-02-26 17:33:38 EST
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
Comment 4 Jeremy Katz 2008-03-02 12:30:55 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.
Comment 5 RHEL Product and Program Management 2008-03-02 12:46:02 EST
Development Management has reviewed and declined this request.  You may appeal
this decision by reopening this request. 
Comment 6 Ritesh Raj Sarraf 2008-05-11 04:38:14 EDT
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.
Comment 7 Brock Organ 2008-06-17 14:17:26 EDT
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 12 Andrius Benokraitis 2008-07-17 10:08:25 EDT
Reopening to keep on the RHEL 6.0 list assuming the Fedora bug gets integrated.
Comment 13 Andrius Benokraitis 2008-07-17 10:08:59 EDT
Bug 455693 created for Fedora.
Comment 14 Ritesh Raj Sarraf 2008-09-10 06:45:03 EDT
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.
Comment 15 Bill Nottingham 2008-09-25 17:03:30 EDT
We don't normally confine the root user, which is what would be required here.
Comment 16 Ritesh Raj Sarraf 2009-02-05 06:29:50 EST
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.
Comment 17 Andrius Benokraitis 2009-02-05 11:45:21 EST
Something like this *definitely* needs to be in Fedora first before it even gets a whiff of RHEL. Moving to Fedora.
Comment 20 Ritesh Raj Sarraf 2009-02-05 15:25:28 EST
(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
Comment 22 Hans de Goede 2010-01-12 10:32:37 EST
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.

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