From: David Howells <dhowells@redhat.com> To: "Austin S. Hemmelgarn" <ahferroin7@gmail.com>, alexei.starovoitov@gmail.com, ard.biesheuvel@linaro.org Cc: dhowells@redhat.com, linux-kernel@vger.kernel.org, gnomes@lxorguk.ukuu.org.uk, linux-efi@vger.kernel.org, matthew.garrett@nebula.com, gregkh@linuxfoundation.org, linux-security-module@vger.kernel.org, keyrings@vger.kernel.org, jlee@suse.com Subject: Why kernel lockdown? Date: Tue, 11 Apr 2017 00:15:31 +0100 [thread overview] Message-ID: <8559.1491866131@warthog.procyon.org.uk> (raw) In-Reply-To: <25acabf2-ac99-3c2b-ee9a-53d71b5c77f2@gmail.com> Alexei Starovoitov <alexei.starovoitov@gmail.com> wrote: > Also is there a description of what this lockdown trying to accomplish? Austin S. Hemmelgarn <ahferroin7@gmail.com> wrote: > ... but for any kind of proper security analysis, you need to better clarify > your threat model. 'Prevent modification to the running kernel image' is a > decent start on this, but at least some of the patches don't explain very > well _how_ what you're disabling could be used to modify the running kernel > image. Clarifying how something is a threat will help with verifying that > you're correctly blocking the threat. The idea is to properly implement UEFI Secure Boot mode such that we can kexec another operating system (Linux, Windows, etc.) and pass on the Secure Boot flag with a guarantee that we haven't been compromised. This assumes the following: (1) Someone wanting to compromise your machine can't get physical access to the running hardware. I think pretty much all bets are off if someone gets their hands on your computer. (2) Whatever boots our kernel is not itself compromised. If it is, there's pretty much nothing we can do about it. (3) Whatever boots our kernel can prove that our kernel is what it says it is. Now, (2) has to start with security right from the system booting, and likely involves the firmware being checked by the hardware. The firmware then has to validate anything it runs, and the things it runs have to validate anything they run, etc. up to our kernel being booted. With regard to (3), take the example of booting Fedora Linux on a UEFI PC in secure boot mode: the UEFI BIOS boots the Fedora SHIM, which boots Grub, which boots the kernel. The SHIM is signed by the UEFI signing authority and is checked against the UEFI key database; Grub and the kernel are signed by a key built into the SHIM. [Note that in secure boot mode, Grub loads the kernel image asks the SHIM to verify it; further, the SHIM will catch anyone trying to boot without verification and halt the machine.] [Note that we do verification with cryptographic signatures, but compiled-in hash whitelists would also work.] In order to maintain the security guarantee, the kernel then needs to prevent unauthorised modification of code and data in the running kernel (module loading is permissible) and also it needs to protect any private keys or other security data it may hold within the image. We try to do this by the following means: (1) Refuse to use any key or hash that UEFI has in its blacklist. (2) Refuse to load any module that isn't signed/hashed. (3) Refuse to load any firmware that isn't signed/hashed. (4) Refuse to kexec any image that isn't signed/hashed. (5) Refuse to dump a kernel image for software suspend/hibernation if it's not encrypted. Further, if it is encrypted, the key must be protected. (6) Refuse to load a dumped kernel image that isn't encrypted with a protected key. (7) Refuse to allow userspace direct access to kernel memory (no /dev/mem, /dev/kmem, /proc/kcore). (8) Refuse to allow userspace direct, unsupervised access to hardware (no iopl, /dev/ioports, MSRs, etc.). It might be feasible to open PCI BARs through dedicated device files for certain functions though (eg. X servers), but unconstrained DMA must be disallowed. (9) Refuse to let userspace configure a driver to use a piece of hardware to muck around with system RAM, possibly by mismatching driver and device. > 'Prevent modification to the running kernel image' is a decent start on > this, but at least some of the patches don't explain very well _how_ what > you're disabling could be used to modify the running kernel image. To be honest, I don't know in all cases since I'm taking a collection of patches not all of which are written by me. I can see how most of them work, but some of the more esoteric things, like ACPI... > Furthermore, why is the only way to enable this to boot in UEFI Secure Boot > mode? There's no reason that this need be the case, but it's the one I'm interested in. But do note assumption (2) above. I can provide kernel lockdown in other situations, but can't forward the guarantee if I wasn't given one to begin with. David
WARNING: multiple messages have this Message-ID (diff)
From: dhowells@redhat.com (David Howells) To: linux-security-module@vger.kernel.org Subject: Why kernel lockdown? Date: Tue, 11 Apr 2017 00:15:31 +0100 [thread overview] Message-ID: <8559.1491866131@warthog.procyon.org.uk> (raw) In-Reply-To: <25acabf2-ac99-3c2b-ee9a-53d71b5c77f2@gmail.com> Alexei Starovoitov <alexei.starovoitov@gmail.com> wrote: > Also is there a description of what this lockdown trying to accomplish? Austin S. Hemmelgarn <ahferroin7@gmail.com> wrote: > ... but for any kind of proper security analysis, you need to better clarify > your threat model. 'Prevent modification to the running kernel image' is a > decent start on this, but at least some of the patches don't explain very > well _how_ what you're disabling could be used to modify the running kernel > image. Clarifying how something is a threat will help with verifying that > you're correctly blocking the threat. The idea is to properly implement UEFI Secure Boot mode such that we can kexec another operating system (Linux, Windows, etc.) and pass on the Secure Boot flag with a guarantee that we haven't been compromised. This assumes the following: (1) Someone wanting to compromise your machine can't get physical access to the running hardware. I think pretty much all bets are off if someone gets their hands on your computer. (2) Whatever boots our kernel is not itself compromised. If it is, there's pretty much nothing we can do about it. (3) Whatever boots our kernel can prove that our kernel is what it says it is. Now, (2) has to start with security right from the system booting, and likely involves the firmware being checked by the hardware. The firmware then has to validate anything it runs, and the things it runs have to validate anything they run, etc. up to our kernel being booted. With regard to (3), take the example of booting Fedora Linux on a UEFI PC in secure boot mode: the UEFI BIOS boots the Fedora SHIM, which boots Grub, which boots the kernel. The SHIM is signed by the UEFI signing authority and is checked against the UEFI key database; Grub and the kernel are signed by a key built into the SHIM. [Note that in secure boot mode, Grub loads the kernel image asks the SHIM to verify it; further, the SHIM will catch anyone trying to boot without verification and halt the machine.] [Note that we do verification with cryptographic signatures, but compiled-in hash whitelists would also work.] In order to maintain the security guarantee, the kernel then needs to prevent unauthorised modification of code and data in the running kernel (module loading is permissible) and also it needs to protect any private keys or other security data it may hold within the image. We try to do this by the following means: (1) Refuse to use any key or hash that UEFI has in its blacklist. (2) Refuse to load any module that isn't signed/hashed. (3) Refuse to load any firmware that isn't signed/hashed. (4) Refuse to kexec any image that isn't signed/hashed. (5) Refuse to dump a kernel image for software suspend/hibernation if it's not encrypted. Further, if it is encrypted, the key must be protected. (6) Refuse to load a dumped kernel image that isn't encrypted with a protected key. (7) Refuse to allow userspace direct access to kernel memory (no /dev/mem, /dev/kmem, /proc/kcore). (8) Refuse to allow userspace direct, unsupervised access to hardware (no iopl, /dev/ioports, MSRs, etc.). It might be feasible to open PCI BARs through dedicated device files for certain functions though (eg. X servers), but unconstrained DMA must be disallowed. (9) Refuse to let userspace configure a driver to use a piece of hardware to muck around with system RAM, possibly by mismatching driver and device. > 'Prevent modification to the running kernel image' is a decent start on > this, but at least some of the patches don't explain very well _how_ what > you're disabling could be used to modify the running kernel image. To be honest, I don't know in all cases since I'm taking a collection of patches not all of which are written by me. I can see how most of them work, but some of the more esoteric things, like ACPI... > Furthermore, why is the only way to enable this to boot in UEFI Secure Boot > mode? There's no reason that this need be the case, but it's the one I'm interested in. But do note assumption (2) above. I can provide kernel lockdown in other situations, but can't forward the guarantee if I wasn't given one to begin with. David -- To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to majordomo at vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2017-04-10 23:15 UTC|newest] Thread overview: 211+ messages / expand[flat|nested] mbox.gz Atom feed top 2017-04-05 20:14 [PATCH 00/24] Kernel lockdown David Howells 2017-04-05 20:14 ` David Howells 2017-04-05 20:14 ` [PATCH 01/24] efi: Add EFI_SECURE_BOOT bit David Howells 2017-04-05 20:14 ` David Howells 2017-04-06 8:26 ` Ard Biesheuvel 2017-04-06 8:26 ` Ard Biesheuvel 2017-04-06 8:48 ` David Howells 2017-04-06 8:48 ` David Howells 2017-04-05 20:14 ` [PATCH 02/24] Add the ability to lock down access to the running kernel image David Howells 2017-04-05 20:14 ` David Howells 2017-04-05 20:14 ` David Howells 2017-04-05 20:14 ` [PATCH 03/24] efi: Lock down the kernel if booted in secure boot mode David Howells 2017-04-05 20:14 ` David Howells 2017-04-05 20:15 ` [PATCH 04/24] Enforce module signatures if the kernel is locked down David Howells 2017-04-05 20:15 ` David Howells 2017-04-05 20:15 ` [PATCH 05/24] Restrict /dev/mem and /dev/kmem when " David Howells 2017-04-05 20:15 ` David Howells 2017-04-05 20:15 ` [PATCH 06/24] Add a sysrq option to exit secure boot mode David Howells 2017-04-05 20:15 ` David Howells 2017-04-14 18:05 ` Thomas Gleixner 2017-04-14 18:05 ` Thomas Gleixner 2017-04-14 18:05 ` Thomas Gleixner 2017-04-14 18:15 ` Ard Biesheuvel 2017-04-14 18:15 ` Ard Biesheuvel 2017-04-14 18:15 ` Ard Biesheuvel 2017-04-14 23:16 ` David Howells 2017-04-14 23:16 ` David Howells 2017-04-14 23:16 ` David Howells 2017-04-16 20:46 ` Matt Fleming 2017-04-16 20:46 ` Matt Fleming 2017-04-16 20:46 ` Matt Fleming 2017-04-05 20:15 ` [PATCH 07/24] kexec: Disable at runtime if the kernel is locked down David Howells 2017-04-05 20:15 ` David Howells 2017-04-05 20:15 ` David Howells 2017-04-07 3:07 ` Dave Young 2017-04-07 3:07 ` Dave Young 2017-04-07 3:07 ` Dave Young 2017-04-07 3:07 ` Dave Young 2017-04-05 20:15 ` [PATCH 08/24] Copy secure_boot flag in boot params across kexec reboot David Howells 2017-04-05 20:15 ` David Howells 2017-04-05 20:15 ` David Howells 2017-04-05 20:15 ` [PATCH 09/24] kexec_file: Disable at runtime if securelevel has been set David Howells 2017-04-05 20:15 ` David Howells 2017-04-05 20:15 ` David Howells 2017-04-05 20:15 ` David Howells 2017-04-07 3:05 ` Dave Young 2017-04-07 3:05 ` Dave Young 2017-04-07 3:05 ` Dave Young 2017-04-07 3:05 ` Dave Young 2017-04-07 3:49 ` Mimi Zohar 2017-04-07 3:49 ` Mimi Zohar 2017-04-07 3:49 ` Mimi Zohar 2017-04-07 6:19 ` Dave Young 2017-04-07 6:19 ` Dave Young 2017-04-07 6:19 ` Dave Young 2017-04-07 6:19 ` Dave Young 2017-04-07 7:45 ` Mimi Zohar 2017-04-07 7:45 ` Mimi Zohar 2017-04-07 7:45 ` Mimi Zohar 2017-04-07 8:01 ` Dave Young 2017-04-07 8:01 ` Dave Young 2017-04-07 8:01 ` Dave Young 2017-04-07 7:07 ` David Howells 2017-04-07 7:07 ` David Howells 2017-04-07 7:07 ` David Howells 2017-04-07 7:41 ` Dave Young 2017-04-07 7:41 ` Dave Young 2017-04-07 7:41 ` Dave Young 2017-04-07 7:41 ` Dave Young 2017-04-07 8:28 ` Mimi Zohar 2017-04-07 8:28 ` Mimi Zohar 2017-04-07 8:28 ` Mimi Zohar 2017-04-07 8:28 ` Mimi Zohar 2017-04-07 8:42 ` Dave Young 2017-04-07 8:42 ` Dave Young 2017-04-07 8:42 ` Dave Young 2017-04-07 8:42 ` Dave Young 2017-04-07 7:09 ` David Howells 2017-04-07 7:09 ` David Howells 2017-04-07 7:09 ` David Howells 2017-04-07 7:46 ` Mimi Zohar 2017-04-07 7:46 ` Mimi Zohar 2017-04-07 7:46 ` Mimi Zohar 2017-04-07 9:17 ` David Howells 2017-04-07 9:17 ` David Howells 2017-04-07 9:17 ` David Howells 2017-04-07 12:36 ` Mimi Zohar 2017-04-07 12:36 ` Mimi Zohar 2017-04-07 12:36 ` Mimi Zohar 2017-04-10 13:19 ` David Howells 2017-04-10 13:19 ` David Howells 2017-04-10 13:19 ` David Howells 2017-05-02 19:01 ` Mimi Zohar 2017-05-02 19:01 ` Mimi Zohar 2017-05-02 19:01 ` Mimi Zohar 2017-05-02 19:01 ` Mimi Zohar 2017-04-05 20:16 ` [PATCH 10/24] hibernate: Disable when the kernel is locked down David Howells 2017-04-05 20:16 ` David Howells 2017-04-05 20:16 ` [PATCH 11/24] uswsusp: " David Howells 2017-04-05 20:16 ` David Howells 2017-04-05 23:38 ` Rafael J. Wysocki 2017-04-05 23:38 ` Rafael J. Wysocki 2017-04-05 23:38 ` Rafael J. Wysocki 2017-04-06 6:39 ` Oliver Neukum 2017-04-06 6:39 ` Oliver Neukum 2017-04-06 8:41 ` David Howells 2017-04-06 8:41 ` David Howells 2017-04-06 20:09 ` Rafael J. Wysocki 2017-04-06 20:09 ` Rafael J. Wysocki 2017-04-06 20:09 ` Rafael J. Wysocki 2017-04-06 20:12 ` Rafael J. Wysocki 2017-04-06 20:12 ` Rafael J. Wysocki 2017-04-06 20:25 ` Jiri Kosina 2017-04-06 20:25 ` Jiri Kosina 2017-04-08 3:28 ` poma 2017-04-08 3:28 ` poma 2017-04-12 13:44 ` joeyli 2017-04-12 13:44 ` joeyli 2017-04-06 6:55 ` David Howells 2017-04-06 6:55 ` David Howells 2017-04-06 20:07 ` Rafael J. Wysocki 2017-04-06 20:07 ` Rafael J. Wysocki 2017-04-05 20:16 ` [PATCH 12/24] PCI: Lock down BAR access " David Howells 2017-04-05 20:16 ` David Howells 2017-04-18 17:50 ` Bjorn Helgaas 2017-04-18 17:50 ` Bjorn Helgaas 2017-04-18 17:50 ` Bjorn Helgaas 2017-04-05 20:16 ` [PATCH 13/24] x86: Lock down IO port " David Howells 2017-04-05 20:16 ` David Howells 2017-04-05 20:16 ` David Howells 2017-04-14 18:28 ` Thomas Gleixner 2017-04-14 18:28 ` Thomas Gleixner 2017-04-14 18:28 ` Thomas Gleixner 2017-04-05 20:16 ` [PATCH 14/24] x86: Restrict MSR " David Howells 2017-04-05 20:16 ` David Howells 2017-04-14 18:30 ` Thomas Gleixner 2017-04-14 18:30 ` Thomas Gleixner 2017-04-05 20:16 ` [PATCH 15/24] asus-wmi: Restrict debugfs interface " David Howells 2017-04-05 20:16 ` David Howells 2017-04-07 10:25 ` Andy Shevchenko 2017-04-07 10:25 ` Andy Shevchenko 2017-04-07 12:50 ` David Howells 2017-04-07 12:50 ` David Howells 2017-04-09 11:10 ` Andy Shevchenko 2017-04-09 11:10 ` Andy Shevchenko 2017-04-10 13:16 ` David Howells 2017-04-10 13:16 ` David Howells 2017-04-18 6:06 ` Andy Shevchenko 2017-04-18 6:06 ` Andy Shevchenko 2017-04-18 6:06 ` Andy Shevchenko 2017-04-18 14:34 ` Ben Hutchings 2017-04-18 14:34 ` Ben Hutchings 2017-04-18 14:55 ` David Howells 2017-04-18 14:55 ` David Howells 2017-04-18 14:55 ` David Howells 2017-04-18 15:19 ` Ben Hutchings 2017-04-18 15:19 ` Ben Hutchings 2017-04-18 15:34 ` David Howells 2017-04-18 15:34 ` David Howells 2017-04-18 15:34 ` David Howells 2017-04-18 15:30 ` David Howells 2017-04-18 15:30 ` David Howells 2017-04-18 17:39 ` Ben Hutchings 2017-04-18 17:39 ` Ben Hutchings 2017-04-18 17:39 ` Ben Hutchings 2017-04-05 20:16 ` [PATCH 16/24] ACPI: Limit access to custom_method " David Howells 2017-04-05 20:16 ` David Howells 2017-04-05 20:16 ` [PATCH 17/24] acpi: Ignore acpi_rsdp kernel param when the kernel has been " David Howells 2017-04-05 20:16 ` David Howells 2017-04-06 19:43 ` Rafael J. Wysocki 2017-04-06 19:43 ` Rafael J. Wysocki 2017-04-07 6:31 ` Dave Young 2017-04-07 6:31 ` Dave Young [not found] ` <20170407063107.GA10451-0VdLhd/A9Pl+NNSt+8eSiB/sF2h8X+2i0E9HWUfgJXw@public.gmane.org> 2017-04-07 7:05 ` David Howells 2017-04-07 7:05 ` David Howells 2017-04-07 7:05 ` David Howells 2017-04-07 7:39 ` Dave Young 2017-04-07 7:39 ` Dave Young 2017-04-05 20:17 ` [PATCH 18/24] acpi: Disable ACPI table override if the kernel is " David Howells 2017-04-05 20:17 ` David Howells 2017-04-05 20:17 ` [PATCH 19/24] acpi: Disable APEI error injection " David Howells 2017-04-05 20:17 ` David Howells 2017-04-05 20:17 ` [PATCH 20/24] bpf: Restrict kernel image access functions when " David Howells 2017-04-05 20:17 ` David Howells 2017-04-06 12:29 ` Alexei Starovoitov 2017-04-06 12:29 ` Alexei Starovoitov 2017-04-06 12:40 ` Ard Biesheuvel 2017-04-06 12:40 ` Ard Biesheuvel 2017-04-12 14:57 ` joeyli 2017-04-12 14:57 ` joeyli 2017-04-12 14:57 ` joeyli 2017-04-13 8:46 ` David Howells 2017-04-13 8:46 ` David Howells 2017-04-05 20:17 ` [PATCH 21/24] scsi: Lock down the eata driver David Howells 2017-04-05 20:17 ` David Howells 2017-04-05 20:17 ` [PATCH 22/24] Prohibit PCMCIA CIS storage when the kernel is locked down David Howells 2017-04-05 20:17 ` David Howells 2017-04-05 20:17 ` David Howells 2017-04-05 20:17 ` [PATCH 23/24] Lock down TIOCSSERIAL David Howells 2017-04-05 20:17 ` David Howells 2017-04-05 20:17 ` David Howells 2017-04-05 20:18 ` [PATCH 24/24] Lock down module params that specify hardware parameters (eg. ioport) David Howells 2017-04-05 20:18 ` David Howells 2017-04-05 20:18 ` David Howells 2017-04-07 15:59 ` [PATCH 00/24] Kernel lockdown Austin S. Hemmelgarn 2017-04-07 15:59 ` Austin S. Hemmelgarn 2017-04-07 16:29 ` Justin Forbes 2017-04-07 16:29 ` Justin Forbes 2017-04-07 16:29 ` Justin Forbes 2017-04-10 23:15 ` David Howells [this message] 2017-04-10 23:15 ` Why kernel lockdown? David Howells
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=8559.1491866131@warthog.procyon.org.uk \ --to=dhowells@redhat.com \ --cc=ahferroin7@gmail.com \ --cc=alexei.starovoitov@gmail.com \ --cc=ard.biesheuvel@linaro.org \ --cc=gnomes@lxorguk.ukuu.org.uk \ --cc=gregkh@linuxfoundation.org \ --cc=jlee@suse.com \ --cc=keyrings@vger.kernel.org \ --cc=linux-efi@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-security-module@vger.kernel.org \ --cc=matthew.garrett@nebula.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.