From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from mx1.redhat.com ([209.132.183.28]) by merlin.infradead.org with esmtp (Exim 4.80.1 #2 (Red Hat Linux)) id 1VqAeM-00072b-MS for kexec@lists.infradead.org; Mon, 09 Dec 2013 23:54:07 +0000 Message-ID: <52A657EC.6080304@redhat.com> Date: Mon, 09 Dec 2013 18:53:16 -0500 From: Rik van Riel MIME-Version: 1.0 Subject: Re: [PATCH] kexec: add sysctl to disable kexec References: <20131209233829.GA3501@www.outflux.net> In-Reply-To: <20131209233829.GA3501@www.outflux.net> List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "kexec" Errors-To: kexec-bounces+dwmw2=twosheds.infradead.org@lists.infradead.org To: Kees Cook Cc: Matthew Garrett , Peter Zijlstra , kexec@lists.infradead.org, linux-kernel@vger.kernel.org, Eric Biederman , Andrew Morton , Ingo Molnar , Vivek Goyal , Mel Gorman On 12/09/2013 06:38 PM, Kees Cook wrote: > 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. Not everybody will be running with selinux, or another LSM security policy, so having this simple knob probably makes sense. OTOH, are the people who run without a fancy security people the same people who are interested in locking down the system? I guess I'll ack the patch, since I see no real downside to having the knob... > Signed-off-by: Kees Cook Acked-by: Rik van Riel -- All rights reversed _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751605Ab3LIXyN (ORCPT ); Mon, 9 Dec 2013 18:54:13 -0500 Received: from mx1.redhat.com ([209.132.183.28]:35797 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750899Ab3LIXyL (ORCPT ); Mon, 9 Dec 2013 18:54:11 -0500 Message-ID: <52A657EC.6080304@redhat.com> Date: Mon, 09 Dec 2013 18:53:16 -0500 From: Rik van Riel User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7 MIME-Version: 1.0 To: Kees Cook CC: linux-kernel@vger.kernel.org, Matthew Garrett , Vivek Goyal , Andrew Morton , Eric Biederman , Ingo Molnar , Peter Zijlstra , Mel Gorman , kexec@lists.infradead.org Subject: Re: [PATCH] kexec: add sysctl to disable kexec References: <20131209233829.GA3501@www.outflux.net> In-Reply-To: <20131209233829.GA3501@www.outflux.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 12/09/2013 06:38 PM, Kees Cook wrote: > 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. Not everybody will be running with selinux, or another LSM security policy, so having this simple knob probably makes sense. OTOH, are the people who run without a fancy security people the same people who are interested in locking down the system? I guess I'll ack the patch, since I see no real downside to having the knob... > Signed-off-by: Kees Cook Acked-by: Rik van Riel -- All rights reversed