[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130908163926.GA19665@kroah.com>
Date: Sun, 8 Sep 2013 09:39:26 -0700
From: Greg KH <gregkh@...uxfoundation.org>
To: Matthew Garrett <matthew.garrett@...ula.com>
Cc: Kees Cook <keescook@...omium.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-efi@...r.kernel.org" <linux-efi@...r.kernel.org>,
"hpa@...or.com" <hpa@...or.com>
Subject: Re: [PATCH V3 08/11] kexec: Disable at runtime if the kernel
enforces module loading restrictions
On Sun, Sep 08, 2013 at 04:24:47PM +0000, Matthew Garrett wrote:
> On Sun, 2013-09-08 at 09:18 -0700, Greg KH wrote:
>
> > I want both, but I don't need signed kexec support because I want to use
> > kexec for a program that I "know" is correct because I validated the
> > disk image it was on before I mounted it. We already have other ways to
> > "verify" things without having to add individual verification of
> > specific pieces.
>
> The kernel has no way to know that your kexec payload is coming from a
> verified image. It'll just as happily take something from an unverified
> image. If you've ensured that there's no way an attacker can call
> kexec_load() on an unverified image, then you don't need signed modules.
But I want, for other reasons (i.e. safety in layers), signed kernel
modules. I also might actually want some debugfs files in some random
driver (like this series removes).
The point is that having a "lockdown" mode is good, I'm not disagreeing
there. Just don't force it on people if they don't want it. Allow them
to pick "lock everything down", or "I want signed modules", or "I don't
want kexec".
Don't lump all of this together such that people can not make that
choice between different things, because some people (i.e. me
specifically), do want them.
Heck, look at Red Hat. They have been shipping signed kernel modules
for _years_ and yet they do not disable kexec. Have they been "doing it
wrong" all of this time? Perhaps people want signed modules just for
support reasons, not "security" reasons.
Don't take away those options.
thanks,
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists