linux-kernel - Re: [RFC PATCH v2 01/13] ima: don't expose runtime

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: <701cd62e1d74e4a35105ff573516857111266e95.camel@linux.ibm.com>
Date: Wed, 26 Mar 2025 09:28:43 -0400
From: Mimi Zohar <zohar@...ux.ibm.com>
To: Nicolai Stange <nstange@...e.de>
Cc: Roberto Sassu <roberto.sassu@...wei.com>,
        Dmitry Kasatkin
 <dmitry.kasatkin@...il.com>,
        Eric Snowberg <eric.snowberg@...cle.com>,
        Jarkko Sakkinen <jarkko@...nel.org>,
        James Bottomley
 <James.Bottomley@...senPartnership.com>,
        linux-integrity@...r.kernel.org, linux-security-module@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH v2 01/13] ima: don't expose runtime_measurements for
 unsupported hashes


> > > I would argue that it's likely that no existing userspace tool is relying
> > > on this fallback logic -- they either wouldn't consume the hash value from
> > > the measurement list directly but recreate it by themselves, as is required
> > > for verification against PCRs, or, if they did, they would somehow assume a
> > > hash algorithm and expect the hashes in the measurement list to be of that
> > > type. If of the latter kind, this could even lead to hard to debug
> > > verification failures. For example, from looking at keylime's current
> > > code, the verifier logic seems to assume that the template hashes found
> > > in the provided measurement list are of the configured 'ima_log_hash_alg'
> > > type. In particular, it does not check against padded SHA1 upon
> > > mismatch.
> > 
> > The downside, if none of the TPM bank hash algorithms are configured as builtin
> > in the kernel, is the lack of a measurement list.
> 
> Yes. Just for the record, going forward SHA256 will be, with [v2 05/13]. So
> unless the SHA256 bank is disabled by firmware, it should be fine then.

When IMA goes into TPM-bypass mode, the measurement list still needs to exist. 
We cannot depend on the SHA256 TPM bank being enabled, nor SHA256 always being
the default IMA file hash algorithm.

For this reason sha256 [v2 05/13] needs to be added to the list of "extra"
hashes, if the TPM sha256 bank is disabled.

Refer to the comments on [02/13] for alternatives.

> > If the purpose of this patch set is to actually remove IMA's dependency on a
> > working SHA-1, at some point the Kconfig "select CRYPTO_SHA1" needs to be
> > removed.  Otherwise the kernel will be built with SHA1 builtin
> > (CONFIG_CRYPTO_SHA1=y).
> 
> I should have described it better. In the first step at least, the goal
> is to remove the runtime dependency only. Because when SHA1's
> ->fips_allowed in crypto/testmgr.c gets flipped to false, SHA1
> instantiation would fail with -ENOENT if the kernel was booted with a
> fips=1 on its command line. Users not interested in FIPS, i.e. the vast
> majority, might still want to use SHA1 and there's no real reason not
> to.

Thank you for the explanation.

> 
> But yes, it would definitely make sense to drop the CRYPTO_SHA1 dep, at
> least at some point. Perhaps by simply moving it to the new
> IMA_COMPAT_FALLBACK_TPM_EXTEND. I would personally not do that now
> though, just in case there'll be some unexpected fallout from this
> series.

As long as there is a way of testing the changes, I'm fine with not removing the
select.


Mimi