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
