lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<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

Powered by Openwall GNU/*/Linux Powered by OpenVZ