Hi Simon, On Tue, 2021-07-13 at 14:48 +0000, THOBY Simon wrote: > Sorry it took me some time before I could write a patch (in addition it's my > first kernel contribution so I'm still learning how things should be done, like > fighting Outlook on the web, giving up on it and moving to Mozilla Thunderbird). Thanks! > > This patch is a follow up on the discussion at > https://lore.kernel.org/linux-integrity/10dde047d76b447f32ca91356599be679b8a76e5.camel@xxxxxxxxxxxxx/t/#m0f8127c6982ef94aa42f5cc13ea83b9f9000917e. > > > This patch was built on top of linux-5.14.0-rc1, and I successfully tested the patch > in the following configurations: > - disabled: no visible impact (as expected) > - with ima_allowed_hashes=sha256,sha512: > - alone: blocks both execution and xattr writes > (tested with `emvctl ima_hash -a md5 <my binary>`) > - with ima_appraise=log: audit logs but still permits access > - with ima_appraise=fix: audit logs but still permits access, however it > doesn't fix the hash (so maybe I should do something about it, because > right now it's basically the same as ima_appraise=log w.r.t. hash > algorithms ?) > - with ima_accept_any_hash: permits access, no warnings whatsoever > Do you want ideas of other configurations that I could test? > > I would also like to point out that I'm more than open to suggestions for > changing the names of the parameters (`ima_allowed_hashes` and > `ima_accept_any_hash`) and the "cause" in the audit log (currently > forbidden-hash-algorithm"), because as you know, "naming things is hard". > > > IMA: add an option to restrict the accepted hash algorithms > > Adds two command-line parameters to limit the hash algorithms > allowed for the security.ima xattr. Having two boot command line paramaters is a good indication that this patch needs to be broken up. Please refer to the section "Separate your changes" in Documentation/process/submitting-patches.rst. The cover letter provides the motivation for the patch set. > This gives users the > ability to ensure their systems will not accept weak hashes, > and potentially increase users trust in their IMA configuration, > because they can ensure only strong collision-resistant hashes > are employed and files generated otherwise will not be accepted. Boot command line options should be minimized as much as possible. Perhaps without defining new kernel boot paramaters there are some additional checks that could be added. For example, on a FIPS enabled system, prevent writing non FIPS allowed file signatures, limit file signature algorithms to those enabled on the system, define new policy rules to limit the permitted hash algorithms. thanks, Mimi > > The main point is to safeguard users from mislabelling their files > when using userland utilities to update their files, e.g. evmctl > (`evmctl ima_hash` defaults to sha1). Another possible target > would be people that have deployed IMA years ago, possibly using > algorithms that was then deemed sufficiently collision-resistant, > but that proved to be weak with the passage of time (note that this > could also happen in the future with algorithms considered safe today). > This patch also provides a migration path for users. > > The first parameter supplies a list of allowed algorithms to > the kernel, restricting appraisal to files hashed with "strong" > hash algorithms (by default IMA will keep accepting any hash > algorithm, as enabling such a feature by default would both be > backward-incompatible and very probably break real systems). > The second parameter is an escape hatch that adds a weaker form > of backward-compatibility: when activated, IMA apparaisal will > keep working on files hashed with an algorithm not present in > the list, but updates to these files or new writes to the security.ima > xattr will enforce the selected hash algorithms. This may be useful > to perform an online migration from one algorithm to another. > > > Signed-off-by: Simon Thoby <simon.thoby@xxxxxxxxxx>
