lkml.org 
[lkml]   [2013]   [Sep]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [PATCH V3 08/11] kexec: Disable at runtime if the kernel enforces module loading restrictions
    From
    Date
    On Sun, 2013-09-08 at 08:51 -0700, Kees Cook wrote:
    > On Sun, Sep 8, 2013 at 12:24 AM, Greg KH <gregkh@linuxfoundation.org> wrote:
    > > On Sun, Sep 08, 2013 at 06:44:08AM +0000, Matthew Garrett wrote:
    > >> On Sat, 2013-09-07 at 23:40 -0700, Greg KH wrote:
    > >> > If you apply this, you break everyone who is currently relying on kexec
    > >> > (i.e. kdump, bootloaders, etc.), from using signed kernel modules, which
    > >> > personally, seems like a very bad idea.
    > >>
    > >> Enforcing signed modules provides you with no additional security if you
    > >> have kexec enabled. It's better to make that obvious.
    > >
    > > Then document the heck out of it, don't disable a valid use case just
    > > because it possibly could be used in some way that is different from the
    > > original system.
    > >
    > > If you take this to an extreme, kexec shouldn't be here at all, as it
    > > can do anything in the kernel wherever it wants to.
    > >
    > > kexec has nothing to do with signed modules, don't tie them together.
    >
    > It's not accurate to say it has "nothing to do" with signed modules.
    > The purpose of signed modules is to ensure the integrity of the
    > running system against the root user.

    That's not true if you look at the use cases. Distros use signed
    modules to taint the kernel: insert an unsigned one and the kernel
    taints; insert a properly signed one and it doesn't. They use it for
    support to tell if you've been adhering to your contract. That use case
    has nothing to do with security.

    > It was, however, incomplete. Terrible analogy follows: signed modules
    > was locking the front door, but we have all sorts of windows still
    > open. This closes those windows. You're trying to say that shutting
    > windows has nothing to do with lumber locks. While technically true,
    > this is about the intent of the barriers.
    >
    > Anyone currently using signed modules (with sig_enforce) AND kexec is
    > deluding themselves about what the state of their system's ring-0
    > security stance is. Those people should be running without
    > sig_enforce, and if they want both sig_enforce and kexec, then I would
    > expect a follow-up patch from them to provide signed kexec support.

    The analogy is rubbish. I can give away CAP_SYS_MODULE and enforce what
    modules those I've given the permission to can insert by signing them.
    I keep CAP_SYS_BOOT, so they can't use kexec to subvert this.

    Your analogy seems to be giving away the whole root and then crying Dr
    it hurts when I do this ...

    James




    \
     
     \ /
      Last update: 2013-09-08 19:41    [W:7.048 / U:0.072 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site