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

Respectfully, Major, the problem with "It worries me because it does complicated things" is that it's a specious argument. It's like saying "I don't use compilers because they do lots of complicated reoptimization and how can I be sure they're correct?" or "I don't use virtualization because it does scary low-level stuff".

That's one of the reasons you have test environments; to kick the tires on things that sound cool that you don't have experience with. (Though you of course don't need me to tell you that.)

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

Now that I completely agree with. But this isn't at odds with my view. At the end of the day, Ksplice is a tool in your sysadmin toolkit. And in many environments, it makes a lot of sense to use it alongside your other tools.

You *could* reboot your system every month when your Linux vendor releases a new kernel update (and yes, it really is basically once a month). I say, reboot on the schedule you want to reboot -- not the schedule your vendor forces you to. Especially since Ksplice is almost certainly going to let you patch sooner than "schedule some downtime and reboot" would anyway.

- Waseem

(P.S. Totally unrelated: after learning about, I was pleasantly surprised to learn that .sh and .py are also TLDs)

Edited at 2012-03-15 03:41 pm (UTC)

An easy answer: no

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!


Re: An easy answer: no

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

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

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

Re: An easy answer: no

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!

Doesn't seem to be at odds...

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.

Re: Doesn't seem to be at odds...

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.

  • 1

Log in