Re: [PATCH v5 0/5] IMA: restrict the accepted digest algorithms for the security.ima xattr

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

On Wed, 2021-07-28 at 13:21 +0000, THOBY Simon wrote:
> IMA protects files by storing a hash (or a signature thereof) of their
> content in the security.ima xattr. While the security.ima xattr itself
> is protected by EVM with either a HMAC or a digital signature, no
> mechanism is currently in place to ensure that the security.ima xattr
> was generated with a strong digest algorithm, and any hash defined
> in the kernel will be accepted, even obsolete format like MD4 and MD5.
> 
> The kernel itself will only write this xattr with the 'ima_hash' parameter,
> fixed at init, but it will also happily accept userland writes for said
> xattr, and those writes may use arbitrary hash algorithms as long as the
> kernel have support for it.
> 
> One important point is safeguarding users from mislabelling their
> files when using userland utilities to update their files, as this
> is the kind of behavior one can observe with evmctl (`evmctl ima_hash`
> defaults to sha1). Another group that may be interested is those
> 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 provides a migration path of sorts for these users.
> 
> This patch series gives users the ability to restrict the algorithms
> accepted by their system, both when writing/updating xattrs, and
> when appraising files, while retaining a permissive behavior by default
> to preserve backward compatibility.
> 
> To provide these features, alter the behavior of setxattr to
> only accept hashes built in the kernel, instead of any hash listed
> in the kernel (complete list crypto/hash_info.c). In addition, the
> user can define in his IMA policy the list of digest algorithms
> allowed for writing to the security.ima xattr. In that case,
> only algorithms present in that list are accepted for writing.
> 
> In addition, users may opt-in to whitelisting the hash
> algorithms accepted when appraising thanks to the new
> "appraise_hash" IMA policy option.
> By default IMA will keep accepting any hash algorithm, but specifying
> that option will make appraisal of files hashed with another algorithm
> fail.
> 
> 
> Even when using this option to restrict accepted hashes, a migration
> to a new algorithm is still possible. Suppose your policy states you
> must migrate from 'old_algo' (e.g. sha1) to 'new_algo' (e.g. one of
> sha256/384/512). You can upgrade without relaxing the hash requirements:
> alter your policy rules from 'appraise_hash=old_algo' to
> 'appraise_hash=old_algo,new_algo', load a new SETXATTR_CHECK policy
> rule that accept writes using 'new_algo', reboot, relabel
> all your files with 'new_algo', alter your policy rules from
> 'appraise_hash=old_algo,new_algo' to 'appraise_hash=new_algo',
> and you're done.
> While this represent a significant amount of work, it is important to
> showcase that this patchset is flexible enough to let users upgrade
> if needed.
> 
> 
> This series is based on the following repo/branch:
>  repo: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
>  branch: master
>  commit ff1176468d368232b684f75e82563369208bc371 ("Linux 5.14-rc3")

A few high level comments:

- I recently accepted a couple of patches, which are now in the next-
integrity-testing branch.  When reposting, please rebase this patch set
on top of it.

- The code uses the term "allowed lists", not "white lists", but the
cover letter, patch descriptions, and/or comments still refer to "white
lists".  For an explanation refer to the new section "Naming" in
Documentation/process/coding-style.rst.

- There was some discussion about allowing code longer than 80 columns,
but the section on  "Breaking long lines and strings" in
Documentation/process/coding-style.rst hasn't been updated.  Please
make sure that the new code has a max line length of 80.

thanks,

Mimi