On Thursday 19 Feb 2009 18:05:49 maximilian attems wrote: > On Thu, Feb 19, 2009 at 04:56:20PM +0530, Ritesh Raj Sarraf wrote: > > 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 > 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. > > 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 -- Ritesh Raj Sarraf RESEARCHUT - http://www.researchut.com "Necessity is the mother of invention."
Attachment:
signature.asc
Description: This is a digitally signed message part.
