linux-kernel - [RFC PATCH v1 0/7] ima: get rid of hard dependency on SHA-1

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250313173339.3815589-1-nstange@suse.de>
Date: Thu, 13 Mar 2025 18:33:32 +0100
From: Nicolai Stange <nstange@...e.de>
To: Mimi Zohar <zohar@...ux.ibm.com>,
	Roberto Sassu <roberto.sassu@...wei.com>,
	Dmitry Kasatkin <dmitry.kasatkin@...il.com>
Cc: Eric Snowberg <eric.snowberg@...cle.com>,
	linux-integrity@...r.kernel.org,
	linux-security-module@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	Nicolai Stange <nstange@...e.de>
Subject: [RFC PATCH v1 0/7] ima: get rid of hard dependency on SHA-1

Hi all,

if no SHA-1 implementation was available to the kernel, IMA init would
currently fail, rendering the whole subsystem unusable.

This patch series is an attempt to make SHA-1 availability non-mandatory
for IMA. The main motivation is that NIST announced to sunset SHA-1 by
2030 ([1]), whereby any attempt to instantiate it when booted in FIPS mode
would have to be made to fail with -ENOENT. As this does potentially have
an impact on lifetimes for FIPS certifications issued today, distros might
be interested in disabling SHA-1 downstream soon already.

Anyway, making IMA to work without a SHA-1 implementation available is not
so straightforward, mainly due to that established scheme to substitute
padded SHA-1 template hashes for PCR banks with unmapped/unavailable algos.
There is some userspace around expecting that existing behavior, e.g. the
ima_measurement command from ([2]), and breaking that in certain scenarios
is inevitable.

I tried to make it the least painful possible, and I think I arrived at
a not completely unreasonable solution in the end, but wouldn't be too
surprised if you had a different stance on that. So I would be curious
about your feedback on whether this is a route worth pursuing any further.
FWIW, the most controversial parts are probably
 - [1/7] ima: don't expose runtime_measurements for unsupported hashes
 - [6/7] ima: invalidate unsupported PCR banks once at first use

Note that I haven't tested this series thoroughly yet -- for the time being
I only ran a couple of brief smoke tests in a VM w/o a TPM  (w/ and w/o
SHA-1 disabled of course).

Many thanks!

Nicolai

[1] https://www.nist.gov/news-events/news/2022/12/nist-retires-sha-1-cryptographic-algorithm
[2] https://github.com/linux-integrity/ima-evm-utils.git

Nicolai Stange (7):
  ima: don't expose runtime_measurements for unsupported hashes
  ima: always create runtime_measurements sysfs file for ima_hash
  ima: move INVALID_PCR() to ima.h
  ima: track the set of PCRs ever extended
  tpm: enable bank selection for PCR extend
  ima: invalidate unsupported PCR banks once at first use
  ima: make SHA1 non-mandatory

 drivers/char/tpm/tpm-interface.c      | 29 +++++++++-
 drivers/char/tpm/tpm.h                |  3 +-
 drivers/char/tpm/tpm2-cmd.c           | 29 +++++++++-
 include/linux/tpm.h                   |  3 +
 security/integrity/ima/Kconfig        | 14 +++++
 security/integrity/ima/ima.h          |  9 +++
 security/integrity/ima/ima_crypto.c   | 83 ++++++++++++++++-----------
 security/integrity/ima/ima_fs.c       | 41 +++++++------
 security/integrity/ima/ima_policy.c   |  5 +-
 security/integrity/ima/ima_queue.c    | 26 ++++++++-
 security/integrity/ima/ima_template.c |  7 +++
 11 files changed, 190 insertions(+), 59 deletions(-)

-- 
2.47.1