Re: [PATCH] IMA: add an option to restrict the accepted hash algorithms

[Mimi Zohar <zohar@linux.ibm.com>]

Hi Simon,

On Fri, 2021-07-16 at 09:18 +0000, THOBY Simon wrote:
> Off the top of my head, I see three main alternatives to expose this
> functionality:
> 1) Instead of supplying them at runtime in the kernel cmdline, add compile-time
> toggles that hardcode in the kernel the list of authorized algorithms and the
> expected behavior (verifying on write and/or verifying on appraisal). It would
> basically be the same thing as the proposed patch, but without involving new
> command line parameters. 

We also want to avoid defining new kernel Kconfig options, as much as
possible.

> 2) Use the ima_hash paramter as the sole authorized algorithm. I suppose this
> is what you meant by "limit file signature algorithms to those enabled on the
> system, unless you meant the algorithms built in the kernel with the
> CRYPTO_* compile options ?

By "limit file signature algorithms to those enabled on the system", I
was referring to the latter, not the"ima_hash" parameter.   That would
at least prevent writing file signatures based on unsupported hash
algorithms.   Thinking about it some more, the "ima_hash" might work
for some cases.  Continued below.

> 3) As you suggested, extend the policy DSL to limit the permitted hash
> algorithms. This yields the added advantage of flexibility: you can decide
> to restrict hashes for only some category of files/file systems, even though
> I'm don't see many use cases for such flexibility (but I hold no doubt
> someone somewhere would find some use to it).

In the embedded case, it's unlikely that different files would use
different hash algorithms for files signatures, but in the general case
different software packages could contain file signatures based on
different hash algorithms.

Defining an appraise rule "hash" option for enforcing sounds good.  The
"hash" option would be an allow list, which could be used for
transitioning from one hash algorithm to another.

In terms of writing the file signatures, the simpliest solution would
be to limit it to the "ima_hash" algorithm.   This might work in the
embedded case, but for the more general case it wouldn't.

> I would love to know if you think one of those alternatives would be better
> suited that the others for IMA, or if you thought of another option.

> As a side note, I would also like to thank profusely Lakshmi for his remarks
> on the patch  description and the process itself, as they will prove quite
> valuable when submitting new revisions of this patch!

Indeed, thanks Lakshmi!

thanks,

Mimi