Previous Entry Share Next Entry
Secure Boot versus Ksplice.
I have been attending many talks on Secure Boot.  The basic idea behind secure boot is to ensure that the bios/bootloader and kernel have not been hacked.  My understanding of how this is done is everything is signed and verified during the bootup.  Nothing can run in the kernel that was not signed and verified.  

Then we Oracle pushing Ksplice.

I can't help but ask the question?

Is ksplice a security disaster waiting to happen?

  • 1

Re: An easy answer: no

(Disclaimer: wdaher and I are in different parts of the same organisation and that's probably not relevant either.)

I'm in two camps. I deal with kernel stuff and I deal with security. So I'm an expert in neither, I guess.

The scary kernel-editing that ksplice does when a ksplice module is inserted already goes on in the kernel. The binary you are running is not the one that was loaded, just ask the xen folk. Secure boot also won't protect you against a bad kernel module; quite apart from anything else the module may not even be on the machine at boot time.

It's very hard to convince some people that they should take the hit and reboot their machine with a new kernel. If you think modules-doing-scary-things are bad you should see the distrust that comes with changing "" to "".

Sometimes the distrust is rational. There are third party kernel modules that will need to be recompiled and tested. And there is the problem of scheduling a one hour window necessary to tear down the application stack and reboot. An hour is probably overkill, but, I was somewhat surprised to find out, it does take half an hour to tear down some of these complicated application stacks and get everything safely saved.

All this because you want to install a patch to fix a vulnerability that no one actually believes that will be exploited. After all, no one has exploited one yet ...

  • 1

Log in