danwalsh

Ksplice worries me because it's making edits to actively running kernel code at a very low level. On top of that, if the server administrator forgets to actually update the kernel using the distribution's package manager, the old insecure kernel will boot up the next time the server reboots.

When it comes right down to it, if your environment can't withstand a reboot for security updates occasionally, you're doing it wrong. ;)

Hi Dan,

(Disclaimer: I'm one of the founders of Ksplice the company, though I think you'll see that that's not relevant if you read on)

Conveniently, there's an easy answer to your question: no, it's not. Here's why:
Ksplice does not require any advance modification to the kernel.

And that's really the beauty of Ksplice. You don't need to boot into a special "Ksplice-enabled" version of the system; we can update the kernel you are already running!

The consequence of that is that we're not introducing anything that increases the security risk. Fundamentally, if you can load kernel modules on the system, you can update the system the way Ksplice does. In fact, the Ksplice updates themselves are just kernel modules.

So, given that, I think the answer to your question is a resounding no :)

On the contrary, since patching with Ksplice is so easy, it means you're going to do it more often -- so you're actually going to close these security holes right when your vendor releases patches, not several weeks later when you finally get around to scheduling downtime.

As an aside, I don't think Ksplice is incompatible with Secure Boot either. I don't know a ton about it, but if you have a system that has loadable kernel modules at all, you have a system that can use Ksplice. (In fact, we've produced Ksplice updates for a system that can only load signed modules, and everything works just fine.)

I hope that clears things up; if not, please let me know!

Thanks,
Waseem

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

I am not a kernel engineer.

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.

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

Secure boot systems will require signed modules, so ksplice updates will have to be signed. It's unclear how that's going to work.

> Is ksplice a security disaster waiting to happen?

Any "security disaster" which gets around Restricted Boot is a GOOD thing! Death to Treacherous Computing!

It doesn't seem to be at odds, because if your kernel is signed, the update could be signed as well. You just need to maintain the chain of trust for the Ksplice updates.

Ideally ksplice would hook into something like the IMA framework to measure whatever patches they're applying to your kernel. You could then get these measurements from a log like they do for loaded modules. Then you'd be reasoning over measurements from your kernel and the modifications made to it at run time.

Not simple by any stretch but it would be pretty complete.