linux-kernel - Re: [PATCH v2] kexec: add sysctl to disable kexec

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: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 11 Dec 2013 13:13:32 -0800
From:	Kees Cook <keescook@...omium.org>
To:	"Eric W. Biederman" <ebiederm@...ssion.com>
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@...r.kernel.org" <linux-doc@...r.kernel.org>,
	kexec@...ts.infradead.org
Subject: Re: [PATCH v2] kexec: add sysctl to disable kexec

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.

-Kees

-- 
Kees Cook
Chrome OS Security
--
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/