[PATCH v2] kexec: add sysctl to disable kexec

[PATCH v2] kexec: add sysctl to disable kexec

[Kees Cook]

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.

Signed-off-by: Kees Cook <keescook@chromium.org>
Acked-by: Rik van Riel <riel@redhat.com>
---
v2:
 - updated sysctl documentation; akpm
---
 Documentation/sysctl/kernel.txt |   13 ++++++++++++-
 include/linux/kexec.h           |    1 +
 kernel/kexec.c                  |    3 ++-
 kernel/sysctl.c                 |   13 +++++++++++++
 4 files changed, 28 insertions(+), 2 deletions(-)

diff --git a/Documentation/sysctl/kernel.txt b/Documentation/sysctl/kernel.txt
index 26b7ee491df8..ca153f958a30 100644
--- a/Documentation/sysctl/kernel.txt
+++ b/Documentation/sysctl/kernel.txt
@@ -33,6 +33,7 @@ show up in /proc/sys/kernel:
 - domainname
 - hostname
 - hotplug
+- kexec_disabled
 - kptr_restrict
 - kstack_depth_to_print       [ X86 only ]
 - l2cr                        [ PPC only ]
@@ -287,6 +288,16 @@ Default value is "/sbin/hotplug".
 
 ==============================================================
 
+kexec_disabled:
+
+A toggle indicating if the kexec_load syscall has been disabled. This
+value defaults to 0 (false: kexec_load enabled), but can be set to 1
+(true: kexec_load disabled). Once true, kexec can no longer be used, and
+the toggle cannot be set back to false. Generally used together with the
+"modules_disabled" sysctl.
+
+==============================================================
+
 kptr_restrict:
 
 This toggle indicates whether restrictions are placed on
@@ -331,7 +342,7 @@ A toggle value indicating if modules are allowed to be loaded
 in an otherwise modular kernel.  This toggle defaults to off
 (0), but can be set true (1).  Once true, modules can be
 neither loaded nor unloaded, and the toggle cannot be set back
-to false.
+to false.  Generally used with the "kexec_disabled" toggle.
 
 ==============================================================
 
diff --git a/include/linux/kexec.h b/include/linux/kexec.h
index d78d28a733b1..a1503ed4dde5 100644
--- a/include/linux/kexec.h
+++ b/include/linux/kexec.h
@@ -170,6 +170,7 @@ unsigned long paddr_vmcoreinfo_note(void);
 
 extern struct kimage *kexec_image;
 extern struct kimage *kexec_crash_image;
+extern int kexec_disabled;
 
 #ifndef kexec_flush_icache_page
 #define kexec_flush_icache_page(page)
diff --git a/kernel/kexec.c b/kernel/kexec.c
index 490afc03627e..9d44ed203ee7 100644
--- a/kernel/kexec.c
+++ b/kernel/kexec.c
@@ -929,6 +929,7 @@ static int kimage_load_segment(struct kimage *image,
  */
 struct kimage *kexec_image;
 struct kimage *kexec_crash_image;
+int kexec_disabled;
 
 static DEFINE_MUTEX(kexec_mutex);
 
@@ -939,7 +940,7 @@ SYSCALL_DEFINE4(kexec_load, unsigned long, entry, unsigned long, nr_segments,
 	int result;
 
 	/* We only trust the superuser with rebooting the system. */
-	if (!capable(CAP_SYS_BOOT))
+	if (!capable(CAP_SYS_BOOT) || kexec_disabled)
 		return -EPERM;
 
 	/*
diff --git a/kernel/sysctl.c b/kernel/sysctl.c
index 34a604726d0b..07869ce3642d 100644
--- a/kernel/sysctl.c
+++ b/kernel/sysctl.c
@@ -62,6 +62,7 @@
 #include <linux/capability.h>
 #include <linux/binfmts.h>
 #include <linux/sched/sysctl.h>
+#include <linux/kexec.h>
 
 #include <asm/uaccess.h>
 #include <asm/processor.h>
@@ -614,6 +615,18 @@ static struct ctl_table kern_table[] = {
 		.proc_handler	= proc_dointvec,
 	},
 #endif
+#ifdef CONFIG_KEXEC
+	{
+		.procname	= "kexec_disabled",
+		.data		= &kexec_disabled,
+		.maxlen		= sizeof(int),
+		.mode		= 0644,
+		/* only handle a transition from default "0" to "1" */
+		.proc_handler	= proc_dointvec_minmax,
+		.extra1		= &one,
+		.extra2		= &one,
+	},
+#endif
 #ifdef CONFIG_MODULES
 	{
 		.procname	= "modprobe",
-- 
1.7.9.5


-- 
Kees Cook
Chrome OS Security

Re: [PATCH v2] kexec: add sysctl to disable kexec

[H. Peter Anvin]

On 12/09/2013 04:16 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.
> 
> Signed-off-by: Kees Cook <keescook@chromium.org>
> Acked-by: Rik van Riel <riel@redhat.com>

So the logic is to load a crashkernel and then lock down the machine
before services, networking etc. are enabled?

	-hpa

Re: [PATCH v2] kexec: add sysctl to disable kexec

[Kees Cook]

On Mon, Dec 9, 2013 at 4:34 PM, H. Peter Anvin <hpa@zytor.com> wrote:
> On 12/09/2013 04:16 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.
>>
>> Signed-off-by: Kees Cook <keescook@chromium.org>
>> Acked-by: Rik van Riel <riel@redhat.com>
>
> So the logic is to load a crashkernel and then lock down the machine
> before services, networking etc. are enabled?

Right, or to just turn it off at boot time if kexec will not be used at all.

-Kees

-- 
Kees Cook
Chrome OS Security

Re: [PATCH v2] kexec: add sysctl to disable kexec

[Vivek Goyal]

On Mon, Dec 09, 2013 at 05:06:10PM -0800, Kees Cook wrote:
> On Mon, Dec 9, 2013 at 4:34 PM, H. Peter Anvin <hpa@zytor.com> wrote:
> > On 12/09/2013 04:16 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.
> >>
> >> Signed-off-by: Kees Cook <keescook@chromium.org>
> >> Acked-by: Rik van Riel <riel@redhat.com>
> >
> > So the logic is to load a crashkernel and then lock down the machine
> > before services, networking etc. are enabled?
> 
> Right, or to just turn it off at boot time if kexec will not be used at all.

kdump kernel is loaded with the help of kdump service. Different distro's
might have different dependencies for that serivce. But recently in fedora
we wait network to come up before starting that service. (So that nfs
targets can be mounted and checked for valid dump destinations).

IOW, crash kernel is loaded quite late in the game (quite a few services
have run and possibly networking is up too). To me, practically one will
disable kdump also if you change state of this knob early.

Thanks
Vivek

Re: [PATCH v2] kexec: add sysctl to disable kexec

[Vivek Goyal]

On Tue, Dec 10, 2013 at 09:35:40AM -0500, Vivek Goyal wrote:
> On Mon, Dec 09, 2013 at 05:06:10PM -0800, Kees Cook wrote:
> > On Mon, Dec 9, 2013 at 4:34 PM, H. Peter Anvin <hpa@zytor.com> wrote:
> > > On 12/09/2013 04:16 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.
> > >>
> > >> Signed-off-by: Kees Cook <keescook@chromium.org>
> > >> Acked-by: Rik van Riel <riel@redhat.com>
> > >
> > > So the logic is to load a crashkernel and then lock down the machine
> > > before services, networking etc. are enabled?
> > 
> > Right, or to just turn it off at boot time if kexec will not be used at all.
> 
> kdump kernel is loaded with the help of kdump service. Different distro's
> might have different dependencies for that serivce. But recently in fedora
> we wait network to come up before starting that service. (So that nfs
> targets can be mounted and checked for valid dump destinations).
> 
> IOW, crash kernel is loaded quite late in the game (quite a few services
> have run and possibly networking is up too). To me, practically one will
> disable kdump also if you change state of this knob early.

Of course it also removes the possibility of re-loading crash kernel
after doing some changes to /etc/kdump.conf (like dump destination or
kernel command line).

I am wondering if it is sufficient to disable kexec jump back
functionality only while retaining kexec and kdump. That seems to be
easiest way to change kernel's data structures.

Thanks
Vivek

Re: [PATCH v2] kexec: add sysctl to disable kexec

[H. Peter Anvin]

Of course it isn't.

Vivek Goyal <vgoyal@redhat.com> wrote:
>On Mon, Dec 09, 2013 at 05:06:10PM -0800, Kees Cook wrote:
>> On Mon, Dec 9, 2013 at 4:34 PM, H. Peter Anvin <hpa@zytor.com> wrote:
>> > On 12/09/2013 04:16 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.
>> >>
>> >> Signed-off-by: Kees Cook <keescook@chromium.org>
>> >> Acked-by: Rik van Riel <riel@redhat.com>
>> >
>> > So the logic is to load a crashkernel and then lock down the
>machine
>> > before services, networking etc. are enabled?
>> 
>> Right, or to just turn it off at boot time if kexec will not be used
>at all.
>
>kdump kernel is loaded with the help of kdump service. Different
>distro's
>might have different dependencies for that serivce. But recently in
>fedora
>we wait network to come up before starting that service. (So that nfs
>targets can be mounted and checked for valid dump destinations).
>
>IOW, crash kernel is loaded quite late in the game (quite a few
>services
>have run and possibly networking is up too). To me, practically one
>will
>disable kdump also if you change state of this knob early.
>
>Thanks
>Vivek

-- 
Sent from my mobile phone.  Please pardon brevity and lack of formatting.

Re: [PATCH v2] kexec: add sysctl to disable kexec

[Vivek Goyal]

On Tue, Dec 10, 2013 at 08:32:38AM -0800, H. Peter Anvin wrote:
> Of course it isn't.

I am not sure what are you trying to say. This is too brief.

Thanks
Vivek

> 
> Vivek Goyal <vgoyal@redhat.com> wrote:
> >On Mon, Dec 09, 2013 at 05:06:10PM -0800, Kees Cook wrote:
> >> On Mon, Dec 9, 2013 at 4:34 PM, H. Peter Anvin <hpa@zytor.com> wrote:
> >> > On 12/09/2013 04:16 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.
> >> >>
> >> >> Signed-off-by: Kees Cook <keescook@chromium.org>
> >> >> Acked-by: Rik van Riel <riel@redhat.com>
> >> >
> >> > So the logic is to load a crashkernel and then lock down the
> >machine
> >> > before services, networking etc. are enabled?
> >> 
> >> Right, or to just turn it off at boot time if kexec will not be used
> >at all.
> >
> >kdump kernel is loaded with the help of kdump service. Different
> >distro's
> >might have different dependencies for that serivce. But recently in
> >fedora
> >we wait network to come up before starting that service. (So that nfs
> >targets can be mounted and checked for valid dump destinations).
> >
> >IOW, crash kernel is loaded quite late in the game (quite a few
> >services
> >have run and possibly networking is up too). To me, practically one
> >will
> >disable kdump also if you change state of this knob early.
> >
> >Thanks
> >Vivek
> 
> -- 
> Sent from my mobile phone.  Please pardon brevity and lack of formatting.

Re: [PATCH v2] kexec: add sysctl to disable kexec

[H. Peter Anvin]

On 12/10/2013 10:33 AM, Vivek Goyal wrote:
> On Tue, Dec 10, 2013 at 08:32:38AM -0800, H. Peter Anvin wrote:
>> Of course it isn't.
> 
> I am not sure what are you trying to say. This is too brief.
> 
> Thanks
> Vivek
> 

Of course it is not sufficient.  Once you can get arbitrary code into
kernel space (CPL 0) you can do anything, and "disabling jump back" is
just a speed bump.

	-hpa

Re: [PATCH v2] kexec: add sysctl to disable kexec

[Vivek Goyal]

On Tue, Dec 10, 2013 at 10:54:00AM -0800, H. Peter Anvin wrote:
> On 12/10/2013 10:33 AM, Vivek Goyal wrote:
> > On Tue, Dec 10, 2013 at 08:32:38AM -0800, H. Peter Anvin wrote:
> >> Of course it isn't.
> > 
> > I am not sure what are you trying to say. This is too brief.
> > 
> > Thanks
> > Vivek
> > 
> 
> Of course it is not sufficient.  Once you can get arbitrary code into
> kernel space (CPL 0) you can do anything, and "disabling jump back" is
> just a speed bump.

Agreed that disabling jump back is only a speed bump.

Kees, so how would be use this knob?

- If I put it in some init script, then root will permission to modify
  and remove it.

- Can one specify sysctl parameters on command line? If yes, then one
  can disable this using kernel command line and in that case kdump will
  be disabled too.

Thanks
Vivek

Re: [PATCH v2] kexec: add sysctl to disable kexec

[Kees Cook]

On Tue, Dec 10, 2013 at 11:14 AM, Vivek Goyal <vgoyal@redhat.com> wrote:
> On Tue, Dec 10, 2013 at 10:54:00AM -0800, H. Peter Anvin wrote:
>> On 12/10/2013 10:33 AM, Vivek Goyal wrote:
>> > On Tue, Dec 10, 2013 at 08:32:38AM -0800, H. Peter Anvin wrote:
>> >> Of course it isn't.
>> >
>> > I am not sure what are you trying to say. This is too brief.
>> >
>> > Thanks
>> > Vivek
>> >
>>
>> Of course it is not sufficient.  Once you can get arbitrary code into
>> kernel space (CPL 0) you can do anything, and "disabling jump back" is
>> just a speed bump.
>
> Agreed that disabling jump back is only a speed bump.
>
> Kees, so how would be use this knob?
>
> - If I put it in some init script, then root will permission to modify
>   and remove it.

Correct. Same applies to changing the kernel itself, yes. However, all
those options require a reboot, and unexpected system reboots should
signal a significant problem to a system owner. :) This is a big step
better than a silent kernel root kit getting installed.

> - Can one specify sysctl parameters on command line? If yes, then one
>   can disable this using kernel command line and in that case kdump will
>   be disabled too.

If they can be set on the command line, I'd like to know about it.
That would let me flip the bit even earlier, since I don't use kexec
at all (and don't need to wait until boot up is done).

-Kees

-- 
Kees Cook
Chrome OS Security

Re: [PATCH v2] kexec: add sysctl to disable kexec

[Eric W. Biederman]

Kees Cook <keescook@chromium.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?

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.

Eric

Re: [PATCH v2] kexec: add sysctl to disable kexec

[Kees Cook]

On Wed, Dec 11, 2013 at 9:52 AM, Eric W. Biederman
<ebiederm@xmission.com> wrote:
> Kees Cook <keescook@chromium.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

Re: [PATCH v2] kexec: add sysctl to disable kexec

[Eric W. Biederman]

Kees Cook <keescook@chromium.org> writes:

> On Wed, Dec 11, 2013 at 9:52 AM, Eric W. Biederman
> <ebiederm@xmission.com> wrote:
>> Kees Cook <keescook@chromium.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

Re: [PATCH v2] kexec: add sysctl to disable kexec

[Kees Cook]

On Wed, Dec 11, 2013 at 3:15 PM, Eric W. Biederman
<ebiederm@xmission.com> wrote:
> Kees Cook <keescook@chromium.org> writes:
>
>> On Wed, Dec 11, 2013 at 9:52 AM, Eric W. Biederman
>> <ebiederm@xmission.com> wrote:
>>> Kees Cook <keescook@chromium.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.

Sure, it seems reasonable to clarify it's purpose. I would like block
_changes_ to the kexec image. In the case of systems not using kexec,
this freezes it to "no kexec image", for those with a crash kernel, it
freezes it to just that image, and makes sure it can't change until
reboot. Blocking LINUX_REBOOT_CMD_KEXEC doesn't make sense in the
latter sense, so it seems like changing the sysctl to
"kexec_load_disable" is the sensible direction. I can send a v3 that
changes the name and clarifies the purpose and potential uses.

-Kees

-- 
Kees Cook
Chrome OS Security

Re: [PATCH v2] kexec: add sysctl to disable kexec

[Eric W. Biederman]

Kees Cook <keescook@chromium.org> writes:

> On Wed, Dec 11, 2013 at 3:15 PM, Eric W. Biederman
> <ebiederm@xmission.com> wrote:
>> Kees Cook <keescook@chromium.org> writes:
>>
>>> On Wed, Dec 11, 2013 at 9:52 AM, Eric W. Biederman
>>> <ebiederm@xmission.com> wrote:
>>>> Kees Cook <keescook@chromium.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.
>
> Sure, it seems reasonable to clarify it's purpose. I would like block
> _changes_ to the kexec image. In the case of systems not using kexec,
> this freezes it to "no kexec image", for those with a crash kernel, it
> freezes it to just that image, and makes sure it can't change until
> reboot. Blocking LINUX_REBOOT_CMD_KEXEC doesn't make sense in the
> latter sense, so it seems like changing the sysctl to
> "kexec_load_disable" is the sensible direction. I can send a v3 that
> changes the name and clarifies the purpose and potential uses.

The name change is definitely needed.

My concern from the conversation.  Is there anyone we actually expect to
use the functionality of loading an image and then disabling kexec_load?

>From the earlier discussion it appeared that no one could actually
figure out how to practically use the functionality of loading a kexec
on panic image and then disabling kexec.  Not to mention the weirdness
caused by cpu/memory hotplug which trigger a need to reload the kexec on
panic kernel.

If there is not a clear use case for limiting ourselves to just the
loaded kexec images my preference would be to make it a big hammer that
disabled kexec_load and LINUX_REBOOT_CMD_KEXEC, as that is easier to
reason about.

Eric