Here is also a short description of the new audit messages, but I can send it in a followup mail if that is not the proper place: When writing the xattr with an algorithm not built in the kernel (here the kernel was built with CONFIG_CRYPTO_MD5 unset), e.g. with "evmctl ima_hash -a md5 /usr/bin/strace": audit(1628066120.418:121): pid=1344 uid=0 auid=0 ses=1 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 op=set_data cause=unavailable-hash-algorithm comm="evmctl" name="/usr/bin/strace" dev="dm-0" ino=2632657 res=0 errno=0 With the same command and the policy rule "appraise func=SETXATTR_CHECK appraise_algos=sha256,sha384,sha512", we get: audit(1628066210.141:127): pid=1362 uid=0 auid=0 ses=1 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 op=set_data cause=denied-hash-algorithm comm="evmctl" name="/usr/bin/strace" dev="dm-0" ino=2632657 res=0 errno=0 Note that the cause is now 'denied-hash-algorithm' instead of 'unavailable-hash-algorithm'. We get that audit message for any algorithm outside of sha256/384/512 (including algorithms not compiled in the kernel like MD5). In a sense, 'denied-hash-algorithm' takes predecence over 'unavailable-hash-algorithm'. When appraising files, e.g. trying to execute a file whose xattr was hashed with sha1 while the policy rule "appraise func=BPRM_CHECK fowner=0 appraise_algos=sha256" is enabled: audit(1628066349.230:130): pid=1369 uid=0 auid=0 ses=1 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 op=collect_data cause=denied-hash-algorithm comm="bash" name="/usr/bin/strace" dev="dm-0" ino=2632657 res=0 errno=0 This series is based on the following repo/branch: repo: https://git.kernel.org/pub/scm/linux/kernel/git/zohar/linux-integrity.git branch: next-integrity-testing commit e37be5343ae2b9419aea1442b07e5d2428b437b4 ("Merge branch 'ima-buffer-measurement-changes-v4' into next-integrity")