[v10,0/9] powerpc: Enabling IMA arch specific secure boot policies

Message

Mimi Zohar Oct. 31, 2019, 3:31 a.m. UTC

This patchset extends the previous version[1] by adding support for
checking against a blacklist of binary hashes.

The IMA subsystem supports custom, built-in, arch-specific policies to
define the files to be measured and appraised. These policies are honored
based on priority, where arch-specific policy is the highest and custom
is the lowest.

PowerNV system uses a Linux-based bootloader to kexec the OS. The
bootloader kernel relies on IMA for signature verification of the OS
kernel before doing the kexec. This patchset adds support for powerpc
arch-specific IMA policies that are conditionally defined based on a
system's secure boot and trusted boot states. The OS secure boot and
trusted boot states are determined via device-tree properties.

The verification needs to be performed only for binaries that are not
blacklisted. The kernel currently only checks against the blacklist of
keys. However, doing so results in blacklisting all the binaries that
are signed by the same key. In order to prevent just one particular
binary from being loaded, it must be checked against a blacklist of
binary hashes. This patchset also adds support to IMA for checking
against a hash blacklist for files. signed by appended signature.

[1] http://patchwork.ozlabs.org/cover/1149262/ 

Changelog:

v10: (Mimi posting patch set on Nayna's behalf)
- Minor patch description changes
- Include comment in process_buffer_measurement()
- Additional patch: Enforcing kernel module appended signatures should
be reflected in "/sys/module/module/parameters/sig_enforce".
- Trimmed Cc list.

v9:
* Includes feedbacks from Michael
  * fix the missing of_node_put()
* Includes Mimi's feedbacks
  * fix the policy show() function to display check_blacklist
  * fix the other comment related and patch description
  * add the example of blacklist in the Patch 7/8
Note: Patch 7/8 is giving errors when checkpatch.pl is run because
of the format of showing measurement record as part of the example. I am
not very sure if that can be fixed as we need to represent the
measurements as is.

v8:
* Updates the Patch Description as per Michael's and Mimi's feedback
* Includes feedbacks from Michael for the device tree and policies
  * removes the arch-policy hack by defining three arrays.
  * fixes related to device-tree calls 
  * other code specific feedbacks
* Includes feedbacks from Mimi on the blacklist
  * generic blacklist function is modified than previous version
  * other coding fixes

v7:
* Removes patch related to dt-bindings as per input from Rob Herring. 
* fixes Patch 1/8 to use new device-tree updates as per Oliver
  feedback to device-tree documentation in skiboot mailing list.
(https://lists.ozlabs.org/pipermail/skiboot/2019-September/015329.html)
* Includes feedbacks from Mimi, Thiago
  * moves function get_powerpc_fw_sb_node() from Patch 1 to Patch 3 
  * fixes Patch 2/8 to use CONFIG_MODULE_SIG_FORCE.
  * updates Patch description in Patch 5/8
  * adds a new patch to add wrapper is_binary_blacklisted()
  * removes the patch that deprecated permit_directio

v6:
* includes feedbacks from Michael Ellerman on the patchset v5
  * removed email ids from comments
  * add the doc for the device-tree
  * renames the secboot.c to secure_boot.c and secboot.h to secure_boot.h
  * other code specific fixes
* split the patches to differentiate between secureboot and trustedboot
state of the system
* adds the patches to support the blacklisting of the binary hash.

v5:
* secureboot state is now read via device tree entry rather than OPAL
secure variables
* ima arch policies are updated to use policy based template for
measurement rules

v4:
* Fixed the build issue as reported by Satheesh Rajendran.

v3:
* OPAL APIs in Patch 1 are updated to provide generic interface based on
key/keylen. This patchset updates kernel OPAL APIs to be compatible with
generic interface.
* Patch 2 is cleaned up to use new OPAL APIs.
* Since OPAL can support different types of backend which can vary in the
variable interpretation, the Patch 2 is updated to add a check for the
backend version
* OPAL API now expects consumer to first check the supported backend version
before calling other secvar OPAL APIs. This check is now added in patch 2.
* IMA policies in Patch 3 is updated to specify appended signature and
per policy template.
* The patches now are free of any EFIisms.

v2:

* Removed Patch 1: powerpc/include: Override unneeded early ioremap
functions
* Updated Subject line and patch description of the Patch 1 of this series
* Removed dependency of OPAL_SECVAR on EFI, CPU_BIG_ENDIAN and UCS2_STRING
* Changed OPAL APIs from static to non-static. Added opal-secvar.h for the
same
* Removed EFI hooks from opal_secvar.c
* Removed opal_secvar_get_next(), opal_secvar_enqueue() and
opal_query_variable_info() function
* get_powerpc_sb_mode() in secboot.c now directly calls OPAL Runtime API
rather than via EFI hooks.
* Fixed log messages in get_powerpc_sb_mode() function.
* Added dependency for PPC_SECURE_BOOT on configs PPC64 and OPAL_SECVAR
* Replaced obj-$(CONFIG_IMA) with obj-$(CONFIG_PPC_SECURE_BOOT) in
arch/powerpc/kernel/Makefile

Mimi Zohar (1):
  powerpc/ima: indicate kernel modules appended signatures are enforced

Nayna Jain (8):
  powerpc: detect the secure boot mode of the system
  powerpc/ima: add support to initialize ima policy rules
  powerpc: detect the trusted boot state of the system
  powerpc/ima: define trusted boot policy
  ima: make process_buffer_measurement() generic
  certs: add wrapper function to check blacklisted binary hash
  ima: check against blacklisted hashes for files with modsig
  powerpc/ima: update ima arch policy to check for blacklist

 Documentation/ABI/testing/ima_policy   |  4 ++
 arch/powerpc/Kconfig                   | 11 +++++
 arch/powerpc/include/asm/secure_boot.h | 29 +++++++++++++
 arch/powerpc/kernel/Makefile           |  2 +
 arch/powerpc/kernel/ima_arch.c         | 78 ++++++++++++++++++++++++++++++++++
 arch/powerpc/kernel/secure_boot.c      | 58 +++++++++++++++++++++++++
 certs/blacklist.c                      |  9 ++++
 include/keys/system_keyring.h          |  6 +++
 include/linux/ima.h                    |  3 +-
 security/integrity/ima/ima.h           | 11 +++++
 security/integrity/ima/ima_appraise.c  | 33 ++++++++++++++
 security/integrity/ima/ima_main.c      | 70 ++++++++++++++++++++----------
 security/integrity/ima/ima_policy.c    | 12 +++++-
 security/integrity/integrity.h         |  1 +
 14 files changed, 302 insertions(+), 25 deletions(-)
 create mode 100644 arch/powerpc/include/asm/secure_boot.h
 create mode 100644 arch/powerpc/kernel/ima_arch.c
 create mode 100644 arch/powerpc/kernel/secure_boot.c

Comments

Lakshmi Ramasubramanian Dec. 9, 2019, 8:27 p.m. UTC | #1

Hi Mimi,

On 10/30/2019 8:31 PM, Mimi Zohar wrote:

> This patchset extends the previous version[1] by adding support for
> checking against a blacklist of binary hashes.
> 
> The IMA subsystem supports custom, built-in, arch-specific policies to
> define the files to be measured and appraised. These policies are honored
> based on priority, where arch-specific policy is the highest and custom
> is the lowest.

Has this change been signed off and merged for the next update of the 
kernel (v5.5)?

thanks,
  -lakshmi

Mimi Zohar Dec. 9, 2019, 9:36 p.m. UTC | #2

On Mon, 2019-12-09 at 12:27 -0800, Lakshmi Ramasubramanian wrote:
> Hi Mimi,
> 
> On 10/30/2019 8:31 PM, Mimi Zohar wrote:
> 
> > This patchset extends the previous version[1] by adding support for
> > checking against a blacklist of binary hashes.
> > 
> > The IMA subsystem supports custom, built-in, arch-specific policies to
> > define the files to be measured and appraised. These policies are honored
> > based on priority, where arch-specific policy is the highest and custom
> > is the lowest.
> 
> Has this change been signed off and merged for the next update of the 
> kernel (v5.5)?

Yes, refer to the linuxppc mailing list archives.

Mimi

[1] https://lists.ozlabs.org/pipermail/linuxppc-dev/

Lakshmi Ramasubramanian Dec. 9, 2019, 11:33 p.m. UTC | #3

Hi Mimi,

>>> Has this change been signed off and merged for the next update of the
>>> kernel (v5.5)?
>>
>> Yes, refer to the linuxppc mailing list archives.
>>
>> Mimi
>>
>> [1] https://lists.ozlabs.org/pipermail/linuxppc-dev/
>>

Just wanted to let you know that I applied my "key measurement" patches 
(that I'd posted last week) in v5.5-rc1 branch and validated the changes.

Verified both the non-deferred and the deferred key processing patches.

Please let me know if you were able to review the changes.

thanks,
  -lakshmi