When IMA appraisal/measurement is enabled for executables, an AUDIT_INTEGRITY_DATA (type=1800) audit message is emitted from ima_collect_measurement() if a process receives SIGKILL while reading a file from a slow-read filesystem.
Configuration: - IMA policy configured: measure func=BPRM_CHECK mask=MAY_EXEC - stacked overlayfs with git binary on squashfs (compressed, read-only filesystem on flash storage) - Kernel version 6.12.68 Steps to reproduce: $ echo 3 > /proc/sys/vm/drop_caches; timeout --signal=KILL 0.05s git Killed $ dmesg | tail -n 1 audit: type=1800 audit(1775843687.948:10): pid=14049 uid=0 auid=72198551 ses=2 op=collect_data cause=failed comm="timeout" name="git" dev="overlay" ino=11529215046068473654 res=0 errno=0 The drop_caches evicts both the page cache (forcing squashfs to re-read and decompress from flash on the next access) and the inode cache (forcing IMA to re-hash). The timeout command execs git and sends SIGKILL after 50ms. During that window, IMA is reading the file page by page in integrity_kernel_read. Since the page cache is cold, the squashfs read path must decompress blocks from flash storage. This IO operation causes the kernel to check for signals and return -EINTR. This propagates up through integrity_kernel_rea to ima_calc_file_hash and finally ima_collect_measurement, which logs the collect_data failure. The log is more commonly observed during boot, when the page cache is cold and all binaries must be read from flash for the first time. Many services may start and stop concurrently, and any process that receives SIGKILL while IMA is reading the file from flash for the first time will produce this audit message. I believe this log is spurious because the process is being killed; therefore, an interrupted file read is the expected outcome. The audit message in this case does not indicate any integrity violations as the file has not been tampered with. Lastly, the log's presence can mislead administrators or monitoring tools into believing a security event occurred when it was only an expected process kill. Questions for the IMA maintainers: 1. Is this the intended behavior? Should ima_collect_measurement still emit the audit log when the failure is due to a fatal signal? 2. If not, could a potential fix be to skip the generation of the audit log in ima_collect_measurement (result == -EINTR && fatal_signal_pending(current))? Thanks, Danny
