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