Tainting the initrd
Hi,
I hope it is not too late to discuss this problem. I have a bugzilla filed for this, filed here:
https://bugzilla.redhat.com/show_bug.cgi?id=435033
The problem described in the above bugzilla entry is about "How do we authenticate initrd images"
We sure have a huge dependency on the initrd. And day-by-day that dependency is increasing. Multipath SAN Boot, NFS et cetera all depend on the proper execution of an initrd image.
We see a lot of problems in the SAN space, where users end up shuffling among 2 versions of HBA drivers. One from the OS Vendor, the other from the HBA vendor. And then we see IHVs and ISVs using their own set of utils to tamper the initrd. This is just an example.
Currently, we don't have a way to identify, like what initrd image has the OS booted from. And we don't have a way to verify whether the initrd image from which the OS has booted from (and ended up with a bug), is the same initrd image that the OS vendor generates.
Since this is a re-write effort, I'd like to know opinions here.
* Do we see this situation as a problem ?
* If yes, how can we overcome it ?
I have some proposals listed in the bugzilla, but all are half-baked. I hope with your help, we can come up with a better approach. Probably, we just need a set of strict and enforcing assumptions.
Ritesh
Signature · 7 lines
If possible, Please CC me when replying. I'm not subscribed to the list. -- To unsubscribe from this list: send the line "unsubscribe initramfs" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
A message that is not in the archive (sent off-list or not yet received): [email protected]
Well, since the original initrd is vendor provided you could simply ask for a md5sum of the current initrd and match it against existing / known initrds...
No?
Thiago Galesi
Quoted 40 lines · Ritesh Raj Sarraf
Hi,
I hope it is not too late to discuss this problem. I have a bugzilla filed for this, filed here:
https://bugzilla.redhat.com/show_bug.cgi?id=435033The problem described in the above bugzilla entry is about "How do we authenticate initrd images"
We sure have a huge dependency on the initrd. And day-by-day that dependency is increasing. Multipath SAN Boot, NFS et cetera all depend on the proper execution of an initrd image.We see a lot of problems in the SAN space, where users end up shuffling among 2 versions of HBA drivers. One from the OS Vendor, the other from the HBA vendor. And then we see IHVs and ISVs using their own set of utils to tamper the initrd. This is just an example.
Currently, we don't have a way to identify, like what initrd image has the OS booted from. And we don't have a way to verify whether the initrd image from which the OS has booted from (and ended up with a bug), is the same initrd image that the OS vendor generates.
Since this is a re-write effort, I'd like to know opinions here.
* Do we see this situation as a problem ?
* If yes, how can we overcome it ?I have some proposals listed in the bugzilla, but all are half-baked. I hope with your help, we can come up with a better approach. Probably, we just need a set of strict and enforcing assumptions.
Ritesh
--
If possible, Please CC me when replying. I'm not subscribed to the list.--
To unsubscribe from this list: send the line "unsubscribe initramfs" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Signature · 6 lines
- Thiago Galesi -- To unsubscribe from this list: send the line "unsubscribe initramfs" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
A message that is not in the archive (sent off-list or not yet received): 82ecf08e0902190357l576547f5s5f156c3e9c64a4aa-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org
Quoted 3 lines · On Thursday 19 Feb 2009 17:27:54 Thiago Galesi wrote:
Well, since the original initrd is vendor provided you could simply ask for a md5sum of the current initrd and match it against existing / known initrds...
No. The initrd image is generated usually from the post-installation scripts of kernel packages. These days these are utilities like update-initramfs, which just get called in from the post-installation script of the kernel package.
So there's no way the OS vendor giving an md5sum, because there is no default initrd shipped by the OS vendor.
Ritesh
Signature · 3 lines
Ritesh Raj Sarraf RESEARCHUT - http://www.researchut.com "Necessity is the mother of invention."
Quoted 5 lines · Ritesh Raj Sarraf
Hi,
I hope it is not too late to discuss this problem. I have a bugzilla filed for this, filed here:
https://bugzilla.redhat.com/show_bug.cgi?id=435033
you seem to also have filed
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=514370
Quoted 10 lines
The problem described in the above bugzilla entry is about "How do we authenticate initrd images"
We sure have a huge dependency on the initrd. And day-by-day that dependency is increasing. Multipath SAN Boot, NFS et cetera all depend on the proper execution of an initrd image.We see a lot of problems in the SAN space, where users end up shuffling among 2 versions of HBA drivers. One from the OS Vendor, the other from the HBA vendor. And then we see IHVs and ISVs using their own set of utils to tamper the initrd. This is just an example.
loading external modules that do s..t is easy to detect, there is the tainting flag for that.
Quoted 5 lines
Currently, we don't have a way to identify, like what initrd image has the OS booted from. And we don't have a way to verify whether the initrd image from which the OS has booted from (and ended up with a bug), is the same initrd image that the OS vendor generates.
Quoted 7 lines
Since this is a re-write effort, I'd like to know opinions here.
* Do we see this situation as a problem ?
* If yes, how can we overcome it ?I have some proposals listed in the bugzilla, but all are half-baked. I hope with your help, we can come up with a better approach. Probably, we just need a set of strict and enforcing assumptions.
as initramfs in Debian based boxes are updated by calls of postinst of various packages. i see a hard time to check that is the vendor supplied one.
Signature · 5 lines
maks -- To unsubscribe from this list: send the line "unsubscribe initramfs" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 10 lines · On Thursday 19 Feb 2009 18:05:49 maximilian attems wrote:
Quoted 5 lines · Ritesh Raj Sarraf
Hi,
I hope it is not too late to discuss this problem. I have a bugzilla filed for this, filed here:
https://bugzilla.redhat.com/show_bug.cgi?id=435033you seem to also have filed
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=514370
Sorry, yes. I filed that recently. And this applies to Debian also. I'd love to see if this could be fixed in Debian also.
Quoted 8 lines
Quoted 4 lines
We see a lot of problems in the SAN space, where users end up shuffling among 2 versions of HBA drivers. One from the OS Vendor, the other from the HBA vendor. And then we see IHVs and ISVs using their own set of utils to tamper the initrd. This is just an example.
loading external modules that do s..t is easy to detect, there is the tainting flag for that.
Oh! Yes. The kernels shipped by vendors do taint the kernel when an unsupported (even a GPL module) module is loaded. So this taint status will be able to solve half of the problem that I've put here.
The other problems would be things like booting itself. The initrd has an important job of, for example:
* Setting up iscsi and logging into the targets
* Setting up multipath and creating the multipathed iscsi devices.
* Mounting and booting with them.
These are important part of the OS and when something fails during initrd, it becomes very difficult to identify as to what really is the culprit there.
In the bugzilla, I put an option about SE Linux MAC restrictions using some policy. But that might not be the right approach to solving the problem. Also root runs unconfined, both under Fedora and Debian. So from root, the initrd is still vulnerable to tampering.
One weired way.
We make the initrd creation/updation utilities only callable through the post- inst of the kernel package. The initrd utils ensure that they are only called from a signed and pristine kernel package from the OS vendor. This way, we _might_ get an initrd image that the OS Vendor wants to see on the users box.
But anyway, this approach is just stupid:
* I myself would like to be able to update initrd images in cases where something went bad. update-initrd kind utils are very helpful there.
* But yes, from a support point, it might make sense. RH, for example, will not support bugs against packages that have been tampered. That includes recompiled packages with different configurations and optimizations.
Ritesh
Signature · 3 lines
Ritesh Raj Sarraf RESEARCHUT - http://www.researchut.com "Necessity is the mother of invention."