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-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <d01f5ae9654ca07aa93cb061b21b79ff5c83aa79.camel@huaweicloud.com>
Date: Tue, 18 Mar 2025 12:00:54 +0100
From: Roberto Sassu <roberto.sassu@...weicloud.com>
To: Nicolai Stange <nstange@...e.de>, Mimi Zohar <zohar@...ux.ibm.com>, 
 Roberto Sassu <roberto.sassu@...wei.com>, Dmitry Kasatkin
 <dmitry.kasatkin@...il.com>, Jarkko Sakkinen <jarkko@...nel.org>
Cc: Eric Snowberg <eric.snowberg@...cle.com>,
 linux-integrity@...r.kernel.org,  linux-security-module@...r.kernel.org,
 linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH v1 0/7] ima: get rid of hard dependency on SHA-1

On Thu, 2025-03-13 at 18:33 +0100, Nicolai Stange wrote:
> 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).

+ Jarkko

Hi Nicolai

thanks a lot for the patches. Still didn't go through them, but if I
understood correctly you assume that the SHA1 PCR bank would be still
seen by IMA.

In light of deprecation of SHA1, is this assumption correct?

I would expect that TPM manufacturers or even the TPM driver would
change to fullfill that.

I guess the first stage would be making sure that the SHA1 PCR bank is
unusable at the TPM driver level. A first thought would be to extend
the SHA1 PCR bank with a random value at boot (or earlier), so that the
remote attestation would never work on that PCR bank. At that point, I
would probably go further and not expose the SHA1 PCR bank at all, so
you would have less problems on IMA side.

The second stage would probably be that the TPM firmware would be
updated, not allowing the SHA1 PCR bank to be allocated.

Other than that, sure, also actions need to be done to remove SHA1
support in IMA (will look at your patches).

Roberto

> 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(-)
> 


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ