danwalsh


Dan Walsh's Blog

Got SELinux?


Previous Entry Share Next Entry
Secure Boot versus Ksplice.
danwalsh
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?

Re: An easy answer: no

danwalsh

2012-03-15 03:27 pm (UTC)

That is good to hear, although I would like to here what other kernel engineers think about it.

I am not a kernel engineer.


Re: An easy answer: no

thargol

2012-03-15 07:32 pm (UTC)

I am not a kernel engineer.

Nor am I. But I like the idea of ksplice precisely because it might allow me to bypass Secure Boot. I want to be the one making my own security decisions about what I run on my machines. Sure, most users aren't capable of doing that, and Secure Boot might buy them some extra security (or more likely, the illusion of it). But I'm not most users.


Re: An easy answer: no

johnhaxby

2012-03-20 09:52 am (UTC)

(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 "123.13.0.1" to "123.13.0.2".

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


You are viewing danwalsh