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
