Message-ID: <87k3fbuggk.fsf@xmission.com>
Date:	Wed, 11 Dec 2013 15:15:55 -0800
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Kees Cook <keescook@...omium.org>
Cc:	LKML <linux-kernel@...r.kernel.org>,
	Rik van Riel <riel@...hat.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Matthew Garrett <matthew.garrett@...ula.com>,
	Vivek Goyal <vgoyal@...hat.com>, Rob Landley <rob@...dley.net>,
	Ingo Molnar <mingo@...nel.org>,
	Peter Zijlstra <peterz@...radead.org>,
	Mel Gorman <mgorman@...e.de>,
	"linux-doc\@vger.kernel.org" <linux-doc@...r.kernel.org>,
	kexec@...ts.infradead.org, "H. Peter Anvin" <hpa@...or.com>
Subject: Re: [PATCH v2] kexec: add sysctl to disable kexec

Kees Cook <keescook@...omium.org> writes:

> On Wed, Dec 11, 2013 at 9:52 AM, Eric W. Biederman
> <ebiederm@...ssion.com> wrote:
>> Kees Cook <keescook@...omium.org> writes:
>>
>>> For general-purpose (i.e. distro) kernel builds it makes sense to build with
>>> CONFIG_KEXEC to allow end users to choose what kind of things they want to do
>>> with kexec. However, in the face of trying to lock down a system with such
>>> a kernel, there needs to be a way to disable kexec (much like module loading
>>> can be disabled). Without this, it is too easy for the root user to modify
>>> kernel memory even when CONFIG_STRICT_DEVMEM and modules_disabled are
>>> set.
>>
>> So let me get this straight.  You object to what happens in sys_reboot
>> so you patch sys_kexec_load?
>
> Yes; it's the entry point for loading the image used for crashes and
> LINUX_REBOOT_CMD_KEXEC.
>
>> You give someone the privilege to boot whatever they want and yet you
>> don't want to support them booting whatever they want?
>>
>> I'm sorry my brain is hurting trying to understand the logic of this
>> patch.
>
> I'm not trying to claim this fixes all attack vectors from a root
> user. That is exceedingly hard. :) However, kexec gives the root user
> a trivial (and undetectable) way to modify the running kernel.
> Providing an option to block sys_kexec_load for systems that will
> never use it (or will use it once at startup) is valuable in several
> situations. There's no reason to make an attacker's job easier, and
> this doesn't get in any one else's way.

I am simply trying to point out your patch is incomplete and silly as
presented.

LINUX_REBOOT_CMD_KEXEC should be disabled if you are calling the sysctl
kexec_disable.  If you want to it to be kexec_load_disable please call
it that.  A kexec_load_disable is a different thing than a
kexec_disable.

A kexec_disable would block both sys_kexec_load and
sys_reboot(LINUX_REBOOT_CMD_KEXEC) and would remove any staged kexec
images.  Allowing you to stop considering kexec past that point from a
security analysis perspective.  That is what it sounds like you want.

What I am asking for is an problem description and an implementation
that are in sync, and a problem description that people can look at and
say was this a complete implementation.

Right now I can not tell what was intended so I can not truly tell if
the patch is correct.  Code with that property does not serve anyone any
good, especially as the kernel evolves.

So please decide if you want kexec_disable or kexec_load_disable, or if
you want something a little more nuanced.

Right now I think a full and complete kexec_disable makes sense.  I
probably won't use it but I think it makes sense.  Your patch
implementiong kexec_load_disable seems to be a half solution that tries
to please everyone and does not serve anyone well.  So I don't see the
point.

Eric
--
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