Re: [PATCH v8 7/8] ima: check against blacklisted hashes for files with modsig

On Sun, 2019-10-20 at 12:06 -0400, Mimi Zohar wrote: > On Sat, 2019-10-19 at 14:06 -0400, Nayna Jain wrote: > > Asymmetric private keys are used to sign multiple files. The kernel > > currently support checking against blacklisted keys. However, if the > > public key is

Re: [PATCH v8 7/8] ima: check against blacklisted hashes for files with modsig

On Sat, 2019-10-19 at 14:06 -0400, Nayna Jain wrote: > Asymmetric private keys are used to sign multiple files. The kernel > currently support checking against blacklisted keys. However, if the > public key is blacklisted, any file signed by the blacklisted key will > automatically fail signature

Re: [PATCH v8 3/8] powerpc: detect the trusted boot state of the system

On Sat, 2019-10-19 at 14:06 -0400, Nayna Jain wrote: > While secure boot permits only properly verified signed kernels to be > booted, trusted boot takes a measurement of the kernel image prior to > boot that can be subsequently compared against good known values via > attestation services. >

Re: [PATCH v8 5/8] ima: make process_buffer_measurement() generic

On Sat, 2019-10-19 at 14:06 -0400, Nayna Jain wrote: > process_buffer_measurement() is limited to measuring the kexec boot > command line. This patch makes process_buffer_measurement() more > generic, allowing it to measure other types of buffer data (e.g. > blacklisted binary hashes or key

Re: [PATCH v8 7/8] ima: check against blacklisted hashes for files with modsig

On Sat, 2019-10-19 at 14:06 -0400, Nayna Jain wrote: > diff --git a/Documentation/ABI/testing/ima_policy > b/Documentation/ABI/testing/ima_policy > index 29ebe9afdac4..4c97afcc0f3c 100644 > --- a/Documentation/ABI/testing/ima_policy > +++ b/Documentation/ABI/testing/ima_policy > @@ -25,6 +25,7

Re: [PATCH v8 2/8] powerpc/ima: add support to initialize ima policy rules

On Sat, 2019-10-19 at 14:06 -0400, Nayna Jain wrote: > index ..65d82ee74ea4 > --- /dev/null > +++ b/arch/powerpc/kernel/ima_arch.c > @@ -0,0 +1,39 @@ > +// SPDX-License-Identifier: GPL-2.0 > +/* > + * Copyright (C) 2019 IBM Corporation > + * Author: Nayna Jain > + */ > + > +#include

Re: [PATCH v8 4/8] powerpc/ima: add measurement rules to ima arch specific policy

On Sat, 2019-10-19 at 14:06 -0400, Nayna Jain wrote: > This patch adds the measurement rules to the arch specific policies on > trusted boot enabled systems. This version does not add rules to the existing arch specific policy, but defines an arch specific trusted boot only policy and a combined

Re: [PATCH v7 7/8] ima: check against blacklisted hashes for files with modsig

On Mon, 2019-10-07 at 21:14 -0400, Nayna Jain wrote: > Asymmetric private keys are used to sign multiple files. The kernel > currently support checking against the blacklisted keys. However, if the > public key is blacklisted, any file signed by the blacklisted key will > automatically fail

Re: [PATCH v7 8/8] powerpc/ima: update ima arch policy to check for blacklist

provides the motivation. ^to make sure that the binary hash is not blacklisted. > > Signed-off-by: Nayna Jain Reviewed-by: Mimi Zohar > --- > arch/powerpc/kernel/ima_arch.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/arch/powerpc/kernel/im

Re: [PATCH v7 6/8] certs: add wrapper function to check blacklisted binary hash

returns -EPERM.     > > Signed-off-by: Nayna Jain This patch description describes what you're doing, not the motivation. Reviewed-by: Mimi Zohar > --- > certs/blacklist.c | 9 + > include/keys/system_keyring.h | 6 ++ > 2 files changed, 15 inse

Re: [PATCH v7 5/8] ima: make process_buffer_measurement() generic

[Cc'ing Prakhar Srivastava] On Mon, 2019-10-07 at 21:14 -0400, Nayna Jain wrote: > An additional measurement record is needed to indicate the blacklisted > binary. The record will measure the blacklisted binary hash. > > This patch makes the function process_buffer_measurement() generic to be >

Re: [PATCH v7 2/8] powerpc: add support to initialize ima policy rules

On Mon, 2019-10-07 at 21:14 -0400, Nayna Jain wrote: > PowerNV systems uses kernel based bootloader, thus its secure boot > implementation uses kernel IMA security subsystem to verify the kernel > before kexec. ^use a Linux based bootloader, which rely on the IMA subsystem to enforce different

Re: [PATCH v6 6/9] ima: make process_buffer_measurement() non static

[Cc'ing Prakhar] On Fri, 2019-09-27 at 10:25 -0400, Nayna Jain wrote: > To add the support for checking against blacklist, it would be needed > to add an additional measurement record that identifies the record > as blacklisted. > > This patch modifies the process_buffer_measurement() and makes

Re: [PATCH v6 3/9] powerpc: add support to initialize ima policy rules

On Tue, 2019-10-01 at 12:07 -0400, Nayna wrote: > > On 09/30/2019 09:04 PM, Thiago Jung Bauermann wrote: > > Hello, > > Hi, > > > > >> diff --git a/arch/powerpc/kernel/ima_arch.c > >> b/arch/powerpc/kernel/ima_arch.c > >> new file mode 100644 > >> index ..39401b67f19e > >> ---

Re: [PATCH v6 5/9] powerpc/ima: add measurement rules to ima arch specific policy

On Fri, 2019-09-27 at 10:25 -0400, Nayna Jain wrote: > This patch adds the measurement rules to the arch specific policies for the > systems with trusted boot. > on trusted boot enabled systems. > Signed-off-by: Nayna Jain Minor comment correction below. Reviewed-by

Re: [PATCH v3 4/4] powerpc: load firmware trusted keys/hashes into kernel keyring

verification and loading of the kernels signed by the boot time keys which > are trusted by firmware. > > Signed-off-by: Nayna Jain Feel free to add my tag after addressing the formatting issues. Reviewed-by: Mimi Zohar > diff --git a/security/integrity/platform_certs/load_powerpc.c

Re: [PATCH v3 3/4] x86/efi: move common keyring handler functions to new file

t; mechanisms of loading the keys/hashes from the firmware. > > > > This patch moves the common code from load_uefi.c to keyring_handler.c > > > > Signed-off-by: Nayna Jain Acked-by: Mimi Zohar > > --- > > security/integrity/Makefile |

Re: [PATCH 2/2 v2] efi: print appropriate status message when loading certificates

> Cc: James Morris > Cc: Serge E. Hallyn" > Cc: David Howells > Cc: Nayna Jain > Cc: Josh Boyer > Cc: Mimi Zohar > Signed-off-by: "Lee, Chun-Yi" > --- > security/integrity/platform_certs/load_uefi.c | 13 - > 1 file changed, 8 in

Re: [PATCH 1/2] efi: add a function for transferring status to string

On Wed, 2019-03-27 at 19:58 +0100, Ard Biesheuvel wrote: > On Sun, 24 Mar 2019 at 01:26, Lee, Chun-Yi wrote: > > > > This function can be used to transfer EFI status code to string > > for printing out debug message. Using this function can improve > > the readability of log. Maybe instead of

Re: [PATCH 3/3] x86/ima: retry detecting secure boot mode

On Fri, 2019-03-08 at 09:51 -0800, Matthew Garrett wrote: > On Fri, Mar 8, 2019 at 5:40 AM Mimi Zohar wrote: > > > > On Thu, 2019-03-07 at 14:50 -0800, Matthew Garrett wrote: > > > Is the issue that it gives incorrect results on the first read, or is > > >

Re: [PATCH 3/3] x86/ima: retry detecting secure boot mode

On Fri, 2019-03-08 at 09:51 -0800, Matthew Garrett wrote: > On Fri, Mar 8, 2019 at 5:40 AM Mimi Zohar wrote: > > > > On Thu, 2019-03-07 at 14:50 -0800, Matthew Garrett wrote: > > > Is the issue that it gives incorrect results on the first read, or is > > >

Re: [PATCH 3/3] x86/ima: retry detecting secure boot mode

On Thu, 2019-03-07 at 14:50 -0800, Matthew Garrett wrote: > On Thu, Mar 7, 2019 at 2:48 PM Mimi Zohar wrote: > > I added this last attempt because I'm seeing this on my laptop, with > > some older, buggy firmware. > > Is the issue that it gives incorrect resu

Re: [PATCH 3/3] x86/ima: retry detecting secure boot mode

On Thu, 2019-03-07 at 14:44 -0800, Matthew Garrett wrote: > On Thu, Mar 7, 2019 at 2:38 PM Justin Forbes wrote: > > On Thu, Mar 7, 2019 at 4:29 PM Matthew Garrett wrote: > >> > >> On Mon, Nov 19, 2018 at 11:57 AM Mimi Zohar wrote: > >> > > >> &g

Re: linux-next: Tree for Feb 20

> Fixes for this have already been proposed, and should appear in -next shortly > > The EFI one is here > https://mail.google.com/mail/u/0/#label/linux-efi/FMfcgxwBVgrQRjglPkWRqRqVclGgVDnB > > Not sure about the IMA one, Mimi should be able to comment ...      I've already commented on the

Re: [PATCH v3 1/2] ima: fix build error redeclaration of enumerator

On Thu, 2019-02-14 at 12:28 -0500, Mimi Zohar wrote: > On Wed, 2019-02-13 at 23:16 +0100, Anders Roxell wrote: > > Commit a893ea15d764 ("tpm: move tpm_chip definition to > > include/linux/tpm.h") introduced a build error when both ima and efi is > > enabled. Wh

Re: [PATCH v3 1/2] ima: fix build error redeclaration of enumerator

On Wed, 2019-02-13 at 23:16 +0100, Anders Roxell wrote: > Commit a893ea15d764 ("tpm: move tpm_chip definition to > include/linux/tpm.h") introduced a build error when both ima and efi is > enabled. What happens is that both headers (ima.h and efi.h) defines the > same 'NONE' constant, and it broke

Re: [PATCH v2 7/7] ima: Support platform keyring for kernel appraisal

On Wed, 2018-12-12 at 16:14 -0200, Thiago Jung Bauermann wrote: [snip] > Subject: [PATCH] ima: Only use the platform keyring if it's enabled > > Signed-off-by: Thiago Jung Bauermann Good catch!  Thanks. Mimi > --- > security/integrity/ima/ima_appraise.c | 3 ++- > 1 file changed, 2

Re: [PATCH v2 0/7] add platform/firmware keys support for kernel verification by IMA

Hi Nayna, On Sun, 2018-12-09 at 01:56 +0530, Nayna Jain wrote: > On secure boot enabled systems, a verified kernel may need to kexec > additional kernels. For example, it may be used as a bootloader needing > to kexec a target kernel or it may need to kexec a crashdump kernel. > In such cases, it

Re: [PATCH 0/7] add platform/firmware keys support for kernel verification by IMA

Hi Nayna, On Sun, 2018-11-25 at 20:44 +0530, Nayna Jain wrote: > On secure boot enabled systems, a verified kernel may need to kexec > additional kernels. For example, it may be used as a bootloader needing > to kexec a target kernel or it may need to kexec a crashdump kernel. > In such cases, it

Re: [PATCH 4/7] efi: Add an EFI signature blob parser

On Sun, 2018-11-25 at 20:44 +0530, Nayna Jain wrote: > From: Dave Howells > > Add a function to parse an EFI signature blob looking for elements of > interest. A list is made up of a series of sublists, where all the > elements in a sublist are of the same type, but sublists can be of >

Re: [PATCH 5/7] efi: Import certificates from UEFI Secure Boot

On Sun, 2018-11-25 at 20:44 +0530, Nayna Jain wrote: > From: Josh Boyer > > New Patch Description: > == > > Secure Boot stores a list of allowed certificates in the 'db' variable. > This patch imports those certificates into the platform keyring. The shim > UEFI bootloader

[PATCH 3/3] x86/ima: retry detecting secure boot mode

The secure boot mode may not be detected on boot for some reason (eg. buggy firmware). This patch attempts one more time to detect the secure boot mode. Signed-off-by: Mimi Zohar --- arch/x86/kernel/Makefile | 2 ++ arch/x86/kernel/ima_arch.c | 46

[PATCH 2/3] selftests/ima: kexec_load syscall test

syscall fails when the kernel CONFIG_KEXEC_VERIFY_SIG option is enabled on systems with secureboot enabled[1]. [1] Detecting secureboot enabled is architecture specific. Signed-off-by: Mimi Zohar --- tools/testing/selftests/Makefile | 1 + tools/testing/selftests/ima/Makefile

[PATCH 1/3] ima: add error mesage to kexec_load

Reject the kexec_load syscall with some indication of the problem. Signed-off-by: Mimi Zohar --- security/integrity/ima/ima_main.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/security/integrity/ima/ima_main.c b/security/integrity/ima/ima_main.c index 41e4771980d5

[PATCH 0/3] selftest/ima: fail kexec_load syscall

ut the test succeeds. selftests: ima: test_kexec_load.sh ./test_kexec_load.sh: kexec_load failed [PASS] ok 1..1 selftests: ima: test_kexec_load.sh [PASS] Mimi Mimi Zohar (3): ima: add error mesage to kexec_load selftests/ima: kexec_load syscall test x86/

Re: [PATCH v5 0/6] Add support for architecture specific IMA policies

On Fri, 2018-10-05 at 23:10 +0530, Nayna Jain wrote: > From: Nayna Jain > > The architecture specific policy, introduced in this patch set, permits > different architectures to define IMA policy rules based on kernel > configuration and system runtime information. > > For example, on x86, there

Re: [PATCH v4 3/6] ima: refactor ima_init_policy()

Hi Nayna, On Wed, 2018-09-26 at 17:52 +0530, Nayna Jain wrote: > +static void add_rules(struct ima_rule_entry *entries, int count, > + enum policy_rule_list file) Using "file" to refer to the policy_rule_list enumeration is unusual.  Please change the variable name to

Re: [PATCH v4 6/6] x86/ima: define arch_get_ima_policy() for x86

Hi Eric, Nayna, On Wed, 2018-09-26 at 17:52 +0530, Nayna Jain wrote: > From: Eric Richter > This patch implements an example arch-specific IMA policy for x86 to > enable measurement and appraisal of any kernel image loaded for kexec, > when CONFIG_KEXEC_VERIFY_SIG is not enabled. > > For

Re: [PATCH v4 4/6] ima: add support for arch specific policies

ry_rules. The memory can then be freed after loading a custom > policy. > - Rename ima_get_arch_policy to arch_get_ima_policy. > Signed-off-by: Mimi Zohar > - Modified ima_init_arch_policy() and ima_init_policy() to use add_rules() > from previous patch. > Signed-off-by

Re: [PATCH v4 5/6] ima: add support for external setting of ima_appraise

Hi Nayna, On Wed, 2018-09-26 at 17:52 +0530, Nayna Jain wrote: > The "ima_appraise" mode defaults to enforcing, unless configured to allow > the boot command line "ima_appraise" option. This patch explicitly sets the > "ima_appraise" mode for the arch specific policy setting. Eventually this

Re: [PATCH v4 2/6] ima: prevent kexec_load syscall based on runtime secureboot flag

[Cc'ing the kexec mailing list, and Seth] On Wed, 2018-09-26 at 17:52 +0530, Nayna Jain wrote: > When CONFIG_KEXEC_VERIFY_SIG is enabled, the kexec_file_load syscall > requires the kexec'd kernel image to be signed. Distros are concerned > about totally disabling the kexec_load syscall. As a

Re: [PATCH v4 1/6] x86/ima: define arch_ima_get_secureboot

[Cc'ing the kexec mailing list, and Seth] On Wed, 2018-09-26 at 17:52 +0530, Nayna Jain wrote: > Distros are concerned about totally disabling the kexec_load syscall. > As a compromise, the kexec_load syscall will only be disabled when > CONFIG_KEXEC_VERIFY_SIG is configured and the system is

Re: [PATCH 3/4] ima: add support for KEXEC_ORIG_KERNEL_CHECK

On Fri, 2018-08-03 at 11:16 -0500, Seth Forshee wrote: > On Fri, Aug 03, 2018 at 10:54:59AM -0400, Mimi Zohar wrote: > > On Fri, 2018-08-03 at 08:11 -0500, Seth Forshee wrote: > > > On Wed, Jul 25, 2018 at 06:31:59PM -0500, Eric Richter wrote: > > > > IMA can verify

Re: [PATCH 3/4] ima: add support for KEXEC_ORIG_KERNEL_CHECK

On Fri, 2018-08-03 at 08:11 -0500, Seth Forshee wrote: > On Wed, Jul 25, 2018 at 06:31:59PM -0500, Eric Richter wrote: > > IMA can verify the signature of kernel images loaded with kexec_file_load, > > but can not verify images loaded with the regular kexec_load syscall. > > Therefore, the

Re: [PATCH v5 2/5] efi: Add embedded peripheral firmware support

On Thu, 2018-05-03 at 22:23 +, Luis R. Rodriguez wrote: > On Tue, May 01, 2018 at 03:27:27PM -0400, Mimi Zohar wrote: > > On Tue, 2018-05-01 at 21:11 +0200, Hans de Goede wrote: > > > Only the pre hook? I believe the post-hook should still be called too, > > >

Re: [PATCH v5 2/5] efi: Add embedded peripheral firmware support

On Tue, 2018-05-01 at 21:11 +0200, Hans de Goede wrote: > Hi, > > On 01-05-18 16:36, Mimi Zohar wrote: > > [Cc'ing linux-security] > > > > On Sun, 2018-04-29 at 11:35 +0200, Hans de Goede wrote: > > [...] > >> diff --git a/drivers/base/firmware_

Re: [PATCH v5 2/5] efi: Add embedded peripheral firmware support

[Cc'ing linux-security] On Sun, 2018-04-29 at 11:35 +0200, Hans de Goede wrote: [...] > diff --git a/drivers/base/firmware_loader/fallback_efi.c > b/drivers/base/firmware_loader/fallback_efi.c > new file mode 100644 > index ..82ba82f48a79 > --- /dev/null > +++

Re: [PATCH v3 2/5] efi: Add embedded peripheral firmware support

On Tue, 2018-04-24 at 23:42 +, Luis R. Rodriguez wrote: > On Tue, Apr 24, 2018 at 12:07:01PM -0400, Mimi Zohar wrote: > > On Tue, 2018-04-24 at 17:09 +0200, Hans de Goede wrote: > > > Hi, > > > > > > On 23-04-18 23:11, Luis R. Rodriguez

Re: [PATCH v3 2/5] efi: Add embedded peripheral firmware support

On Tue, 2018-04-24 at 17:09 +0200, Hans de Goede wrote: > Hi, > > On 23-04-18 23:11, Luis R. Rodriguez wrote: > > Hans, please see use of READING_FIRMWARE_PREALLOC_BUFFER, we'll need a new > > ID > > and security for this type of request so IMA can reject it if the policy is > > configured for

Re: An actual suggestion (Re: [GIT PULL] Kernel lockdown for secure boot)

On Thu, 2018-04-05 at 10:16 +0800, joeyli wrote: > Hi David, > > On Wed, Apr 04, 2018 at 05:17:24PM +0100, David Howells wrote: > > Andy Lutomirski wrote: > > > > > Since this thread has devolved horribly, I'm going to propose a solution. > > > > > > 1. Split the "lockdown"

Re: [PATCH 0/9] KEYS: Blacklisting & UEFI database load

On Sun, 2018-03-11 at 11:20 +0800, joeyli wrote: > On Wed, Mar 07, 2018 at 07:28:37AM -0800, James Bottomley wrote: > > On Wed, 2018-03-07 at 08:18 -0500, Mimi Zohar wrote: > > > On Tue, 2018-03-06 at 15:05 +0100, Jiri Slaby wrote: > > > > what's the status of this p

Re: [PATCH 0/9] KEYS: Blacklisting & UEFI database load

On Tue, 2018-03-06 at 15:05 +0100, Jiri Slaby wrote: > On 11/16/2016, 07:10 PM, David Howells wrote: > > Here are two sets of patches. Firstly, the first three patches provide a > > blacklist, making the following changes: > ... > > Secondly, the remaining patches allow the UEFI database to be

Re: Firmware signing -- Re: [PATCH 00/27] security, efi: Add kernel lockdown

On Wed, 2017-11-15 at 21:46 +0100, Luis R. Rodriguez wrote: > On Wed, Nov 15, 2017 at 02:56:57PM -0500, Mimi Zohar wrote: > > On Wed, 2017-11-15 at 18:52 +0100, Luis R. Rodriguez wrote: > > > On Wed, Nov 15, 2017 at 06:49:57AM -0500, Mimi Zohar wrote: > > > > On

Re: Firmware signing -- Re: [PATCH 00/27] security, efi: Add kernel lockdown

On Wed, 2017-11-15 at 18:52 +0100, Luis R. Rodriguez wrote: > On Wed, Nov 15, 2017 at 06:49:57AM -0500, Mimi Zohar wrote: > > On Tue, 2017-11-14 at 21:50 +0100, Luis R. Rodriguez wrote: > > > > > Johannes made cfg80211 recently just use request_firmware() now via > >

Re: Firmware signing -- Re: [PATCH 00/27] security, efi: Add kernel lockdown

On Tue, 2017-11-14 at 21:50 +0100, Luis R. Rodriguez wrote: > Johannes made cfg80211 recently just use request_firmware() now via commit on > linux-next 90a53e4432 ("cfg80211: implement regdb signature checking") [0] as > he got tired of waiting firmware signing, but note he implemented a

Re: Firmware signing -- Re: [PATCH 00/27] security, efi: Add kernel lockdown

On Tue, 2017-11-14 at 13:38 +0100, Greg Kroah-Hartman wrote: > On Tue, Nov 14, 2017 at 07:21:38AM -0500, Mimi Zohar wrote: > > On Mon, 2017-11-13 at 14:09 -0800, Linus Torvalds wrote: > > > On Mon, Nov 13, 2017 at 1:44 PM, David Howells <dhowe...@redhat.com> > > &

Re: Firmware signing -- Re: [PATCH 00/27] security, efi: Add kernel lockdown

On Mon, 2017-11-13 at 14:09 -0800, Linus Torvalds wrote: > On Mon, Nov 13, 2017 at 1:44 PM, David Howells wrote: > > > > Whilst that may be true, we either have to check signatures on every bit of > > firmware that the appropriate driver doesn't say is meant to be signed or

Re: Firmware signing -- Re: [PATCH 00/27] security, efi: Add kernel lockdown

On Sat, 2017-11-11 at 02:32 +, Alan Cox wrote: > > My assumption here is: > > 1) there are some less important and so security-insensitive firmwares, > >by which I mean that such firmwares won't be expected to be signed in > >terms of vulnerability or integrity. > >(I can't give

Re: Firmware signing -- Re: [PATCH 00/27] security, efi: Add kernel lockdown

On Fri, 2017-11-10 at 02:46 +0100, Luis R. Rodriguez wrote: > On Thu, Nov 09, 2017 at 10:48:43AM +0900, AKASHI, Takahiro wrote: > > On Wed, Nov 08, 2017 at 08:46:26PM +0100, Luis R. Rodriguez wrote: > > > But perhaps I'm not understanding the issue well, let me know. > > > > My point is quite

Re: Firmware signing -- Re: [PATCH 00/27] security, efi: Add kernel lockdown

On Thu, 2017-11-09 at 13:46 +0900, AKASHI, Takahiro wrote: > Mimi, > > On Wed, Nov 08, 2017 at 09:17:37PM -0500, Mimi Zohar wrote: > > > > IMHO that should just fail then, ie, a "locked down" kernel should not > > > > want to > > > > *pas

Re: Firmware signing -- Re: [PATCH 00/27] security, efi: Add kernel lockdown

> > IMHO that should just fail then, ie, a "locked down" kernel should not want > > to > > *pass* a firmware signature if such thing could not be done. > > > > Its no different than trying to verify a signed module on a "locked down" > > for > > which it has no signature. > > > > But perhaps

Re: Firmware signing -- Re: [PATCH 00/27] security, efi: Add kernel lockdown

> > Or reflect that IMA-appraisal, if enabled, will enforce firmware being > > validly signed. > > But FWICT lockdown is a built-in kernel thingy, unless lockdown implies IMA > it would not be the place to refer to it. > > It seems the documentation was proposed to help users if an error was

Re: [PATCH 03/27] Enforce module signatures if the kernel is locked down

On Thu, 2017-11-02 at 22:01 +, David Howells wrote: > Mimi Zohar <zo...@linux.vnet.ibm.com> wrote: > > > Right, it would never get here if the IMA signature verification > > fails.  If sig_enforce is not enabled, then it will also work.  So the > > only case

Re: Firmware signing -- Re: [PATCH 00/27] security, efi: Add kernel lockdown

On Thu, 2017-11-02 at 22:04 +, David Howells wrote: > Mimi Zohar <zo...@linux.vnet.ibm.com> wrote: > > > > Only validly signed device firmware may be loaded. > > > > fw_get_filesystem_firmware() calls kernel_read_file_from_path() to > > read the firmwa

Re: [PATCH 00/27] security, efi: Add kernel lockdown

Hi David, >From the man page: > Only validly signed modules may be loaded. > .P > Only validly signed binaries may be kexec'd. > .P > Only validly signed device firmware may be loaded. fw_get_filesystem_firmware() calls kernel_read_file_from_path() to read the firmware, which calls into the

Re: [PATCH 03/27] Enforce module signatures if the kernel is locked down

On Thu, 2017-11-02 at 21:30 +, David Howells wrote: > Mimi Zohar <zo...@linux.vnet.ibm.com> wrote: > > > By this point, IMA-appraisal has already verified the kernel module > > signature back in kernel_read_file_from_fd(), if it was required. > >  Hav

Re: [PATCH 03/27] Enforce module signatures if the kernel is locked down

On Thu, 2017-11-02 at 17:22 +, David Howells wrote: > #ifdef CONFIG_MODULE_SIG > -static int module_sig_check(struct load_info *info, int flags) > +static int module_sig_check(struct load_info *info, int flags, > + bool can_do_ima_check) > { > int err =

Re: [PATCH 03/27] Enforce module signatures if the kernel is locked down

[Corrected Matthew Garrett's email address.  Cc'ed Bruno Meneguele] On Mon, 2017-10-30 at 17:00 +, David Howells wrote: > Mimi Zohar <zo...@linux.vnet.ibm.com> wrote: > > > This kernel_is_locked_down() check is being called for both the > > original and new module

Re: [PATCH 07/27] kexec_file: Disable at runtime if securelevel has been set

On Mon, 2017-10-30 at 15:49 +, David Howells wrote: > Mimi Zohar <zo...@linux.vnet.ibm.com> wrote: > > > Huh?!  With the "secure_boot" policy enabled on the boot command line, > > IMA-appraisal would verify the kexec kernel image, firmware, kernel > > m

Re: [PATCH 07/27] kexec_file: Disable at runtime if securelevel has been set

On Mon, 2017-10-30 at 09:00 +, David Howells wrote: > Mimi Zohar <zo...@linux.vnet.ibm.com> wrote: > > > Yes, that works.  Thanks!  Remember is_ima_appraise_enabled() is > > dependent on the "ima: require secure_boot rules in lockdown mode" > > pa

Re: [PATCH 07/27] kexec_file: Disable at runtime if securelevel has been set

On Sat, 2017-10-28 at 16:34 +0800, joeyli wrote: > On Fri, Oct 27, 2017 at 03:32:26PM -0400, Mimi Zohar wrote: > > On Thu, 2017-10-26 at 10:17 -0400, Mimi Zohar wrote: > > > On Thu, 2017-10-26 at 15:42 +0800, joeyli wrote: > > > > Hi Mimi, > >

Re: [PATCH 07/27] kexec_file: Disable at runtime if securelevel has been set

On Thu, 2017-10-26 at 10:17 -0400, Mimi Zohar wrote: > On Thu, 2017-10-26 at 15:42 +0800, joeyli wrote: > > Hi Mimi, > > > > Thank you for reviewing. > > > > On Mon, Oct 23, 2017 at 11:54:43AM -0400, Mimi Zohar wrote: > > > On Thu, 2017-10-19 at 15:5

Re: [PATCH 07/27] kexec_file: Disable at runtime if securelevel has been set

On Thu, 2017-10-26 at 10:17 -0400, Mimi Zohar wrote: > On Thu, 2017-10-26 at 15:42 +0800, joeyli wrote: > > Hi Mimi, > > > > Thank you for reviewing. > > > > On Mon, Oct 23, 2017 at 11:54:43AM -0400, Mimi Zohar wrote: > > > On Thu, 2017-10-19 at 15:5

Re: [PATCH 03/27] Enforce module signatures if the kernel is locked down

On Thu, 2017-10-19 at 15:50 +0100, David Howells wrote: > If the kernel is locked down, require that all modules have valid > signatures that we can verify. > > Signed-off-by: David Howells > --- > > kernel/module.c |3 ++- > 1 file changed, 2 insertions(+), 1

Re: [GIT PULL] Kernel lockdown for secure boot

On Thu, 2017-10-26 at 17:37 +0100, David Howells wrote: > Hi James, > > Can you pull this patchset into security/next please? > > It adds kernel lockdown support for EFI secure boot. Note that it doesn't yet > cover: > > bpf - No agreement as to how > ftrace - Recently

Re: [PATCH 07/27] kexec_file: Disable at runtime if securelevel has been set

[Cc'ing Matthew Garrett] On Thu, 2017-10-26 at 16:02 +0100, David Howells wrote: > joeyli wrote: > > > + if (!IS_ENABLED(CONFIG_KEXEC_VERIFY_SIG) && > > + !is_ima_appraise_enabled() && > > + kernel_is_locked_down("kexec of unsigned images")) > > This doesn't seem

Re: [PATCH 07/27] kexec_file: Disable at runtime if securelevel has been set

On Thu, 2017-10-26 at 15:42 +0800, joeyli wrote: > Hi Mimi, > > Thank you for reviewing. > > On Mon, Oct 23, 2017 at 11:54:43AM -0400, Mimi Zohar wrote: > > On Thu, 2017-10-19 at 15:51 +0100, David Howells wrote: > > > From: Chun-Yi Lee <joeyli.ke

Re: [PATCH 07/27] kexec_file: Disable at runtime if securelevel has been set

On Thu, 2017-10-19 at 15:51 +0100, David Howells wrote: > From: Chun-Yi Lee > > When KEXEC_VERIFY_SIG is not enabled, kernel should not loads image > through kexec_file systemcall if securelevel has been set. The patch title and description needs to be updated to refer

Re: [PATCH 09/24] kexec_file: Disable at runtime if securelevel has been set

Hi David, On Mon, 2017-04-10 at 14:19 +0100, David Howells wrote: > Mimi Zohar <zo...@linux.vnet.ibm.com> wrote: > > > From an IMA perspective, either a file hash or signature are valid, > > but for this usage it must be a signature. > > Not necessarily. If I

Re: [PATCH 09/24] kexec_file: Disable at runtime if securelevel has been set

On Fri, 2017-04-07 at 10:17 +0100, David Howells wrote: > Mimi Zohar <zo...@linux.vnet.ibm.com> wrote: > > > > Okay, fair enough. I can stick in an OR with an IS_ENABLED on some IMA > > > symbol. CONFIG_IMA_KEXEC maybe? And also require IMA be enabled? > >

Re: [PATCH 09/24] kexec_file: Disable at runtime if securelevel has been set

On Fri, 2017-04-07 at 15:41 +0800, Dave Young wrote: > On 04/07/17 at 08:07am, David Howells wrote: > > Dave Young wrote: > > > > > > > > + /* Don't permit images to be loaded into trusted kernels if > > > > > > we're not > > > > > > +* going to verify the signature on

Re: [PATCH 09/24] kexec_file: Disable at runtime if securelevel has been set

On Fri, 2017-04-07 at 08:09 +0100, David Howells wrote: > Mimi Zohar <zo...@linux.vnet.ibm.com> wrote: > > > > > + if (!IS_ENABLED(CONFIG_KEXEC_VERIFY_SIG) && > > > > kernel_is_locked_down()) > > > > + return -EPERM; >

Re: [PATCH 09/24] kexec_file: Disable at runtime if securelevel has been set

On Fri, 2017-04-07 at 11:05 +0800, Dave Young wrote: > On 04/05/17 at 09:15pm, David Howells wrote: > > From: Chun-Yi Lee > > > > When KEXEC_VERIFY_SIG is not enabled, kernel should not loads image > > through kexec_file systemcall if securelevel has been set. > > > >

Re: [PATCH 00/12] One more attempt at useful kernel lockdown

On Tue, 2013-09-10 at 12:44 -0700, H. Peter Anvin wrote: On 09/10/2013 12:17 PM, David Lang wrote: In theory these blobs are traceable to a manufacturer. It's not really an indication that it's safe more than it's an indication that it hasn't been changed. But I haven't chased this very

Re: [PATCH 00/12] One more attempt at useful kernel lockdown

On Mon, 2013-09-09 at 11:49 -0400, Matthew Garrett wrote: Some use cases require the ability to ensure that anything running in ring 0 is trusted code. We have support for signing the kernel and kernel modules, but there's still a range of exported kernel interfaces that make it easy to modify

Re: [PATCH 01/12] Security: Add CAP_COMPROMISE_KERNEL

On Tue, 2013-03-19 at 15:47 +1100, James Morris wrote: On Mon, 18 Mar 2013, Matthew Garrett wrote: This patch introduces CAP_COMPROMISE_KERNEL. I'd like to see this named CAP_MODIFY_KERNEL, which is more accurate and less emotive. Otherwise I think core kernel developers will be

Re: [PATCH 01/12] Security: Add CAP_COMPROMISE_KERNEL

On Wed, 2013-03-20 at 16:49 +, Matthew Garrett wrote: On Wed, 2013-03-20 at 12:41 -0400, Mimi Zohar wrote: Matthrew, perhaps you could clarify whether this will be tied to MAC security. Based on the kexec thread, I'm under the impression that is not the intention, or at least

Re: [PATCH 01/12] Security: Add CAP_COMPROMISE_KERNEL

On Wed, 2013-03-20 at 18:12 +, Matthew Garrett wrote: On Wed, 2013-03-20 at 14:01 -0400, Mimi Zohar wrote: Sorry, I'm not sure to which work you're referring. If you're referring to Dmitry's initramfs with digital signature protection patches, then we're speaking about enforcing

Re: [PATCH 01/12] Security: Add CAP_COMPROMISE_KERNEL

On Wed, 2013-03-20 at 20:37 +, Matthew Garrett wrote: On Wed, 2013-03-20 at 15:16 -0400, Mimi Zohar wrote: On Wed, 2013-03-20 at 18:12 +, Matthew Garrett wrote: Well, in the absence of hardcoded in-kernel policy, there needs to be some mechanism for ensuring the integrity