Common Issues and Solutions
Issue 1: System Fails to Boot After IMA Appraisal Enforce Mode Is Enabled with the Default Policy
The default IMA policy may include checks for critical file access processes such as application execution and kernel module loading. If access to these critical files fails, the system may fail to boot. Common causes include:
- The IMA verification certificate is not imported into the kernel, causing the digest list to fail verification.
- The digest list file is not correctly signed, leading to verification failure.
- The digest list file is not imported into the initrd, preventing the digest list from being loaded during the boot process.
- The digest list file does not match the application, causing the application to fail matching the imported digest list.
Enter the system in log mode to locate and fix the issue. Reboot the system, enter the GRUB menu, and modify the boot parameters to start in log mode:
ima_appraise=log
After the system boots, follow the steps below to troubleshoot.
Step 1: Check the IMA certificates in the key ring.
keyctl show %:.builtin_trusted_keys
For openEuler LTS versions, at least the following kernel certificates should exist (for other versions, reference based on their release dates):
Version | Certificate |
---|---|
openEuler 22.03 LTS | private OBS b25e7f66 |
openEuler 22.03 LTS SP1/2/3 | private OBS b25e7f66 |
openeuler <openeuler@compass-ci.com> b675600b | |
openEuler 22.03 LTS SP4 | private OBS b25e7f66 |
openeuler <openeuler@compass-ci.com> b675600b | |
openeuler <openeuler@compass-ci.com> fb37bc6f | |
openEuler 24.03 | openEuler kernel ICA 1: 90bb67eb4b57eb62bf6f867e4f56bd4e19e7d041 |
If you have imported other kernel root certificates, use the keyctl
command to confirm whether the certificates were successfully imported. By default, openEuler does not use the IMA key ring. If you are using it, check whether the user certificates exist in the IMA key ring with the following command:
keyctl show %:.ima
If the issue is that the certificate was not correctly imported, refer to User Certificate Import for troubleshooting.
Step 2: Check if the digest list contains signature information.
Query the digest list files in the current system with the following command:
ls /etc/ima/digest_lists | grep '_list-compact-'
For each digest list file, ensure that one of the following three signature conditions is met:
The digest list file has a corresponding RPM digest list file, and the
security.ima
extended attribute of the RPM digest list file contains a signature value. For example, for the bash package digest list, the digest list file path is:text/etc/ima/digest_lists/0-metadata_list-compact-bash-5.1.8-6.oe2203sp1.x86_64
The RPM digest list path is:
text/etc/ima/digest_lists/0-metadata_list-rpm-bash-5.1.8-6.oe2203sp1.x86_64
Check the RPM digest list signature by ensuring the
security.ima
extended attribute is not empty:shellgetfattr -n security.ima /etc/ima/digest_lists/0-metadata_list-rpm-bash-5.1.8-6.oe2203sp1.x86_64
The
security.ima
extended attribute of the digest list file is not empty:shellgetfattr -n security.ima /etc/ima/digest_lists/0-metadata_list-compact-bash-5.1.8-6.oe2203sp1.x86_64
The digest list file contains signature information at the end. Verify if the file content ends with the
~Module signature appended~
magic string (supported in openEuler 24.03 LTS and later versions):shelltail -c 28 /etc/ima/digest_lists/0-metadata_list-compact-kernel-6.6.0-28.0.0.34.oe2403.x86_64
If the issue is that the digest list does not contain signature information, refer to Digest List File Signing Methods for troubleshooting.
Step 3: Verify the correctness of the digest list signature.
After ensuring that the digest list contains signature information, also ensure that the digest list is signed with the correct private key, meaning the signing private key matches the certificate in the kernel. In addition to manually checking the private key, users can check the dmesg logs or audit logs (default path: /var/log/audit/audit.log) for signature verification failures. A typical log output is as follows:
type=INTEGRITY_DATA msg=audit(1722578008.756:154): pid=3358 uid=0 auid=0 ses=1 subj=unconfined_u:unconfined_r:haikang_t:s0-s0:c0.c1023 op=appraise_data cause=invalid-signature comm="bash" name="/root/0-metadata_list-compact-bash-5.1.8-6.oe2203sp1.x86_64" dev="dm-0" ino=785161 res=0 errno=0UID="root" AUID="root"
If the issue is incorrect signature information, refer to Digest List File Signing Methods for troubleshooting.
Step 4: Check if the digest list file is imported into the initrd.
Query whether the digest list file exists in the current initrd with the following command:
lsinitrd | grep 'etc/ima/digest_lists'
If no digest list file is found, users need to recreate the initrd and verify that the digest list is successfully imported:
dracut -f -e xattr
Step 5: Verify that the IMA digest list matches the application.
Refer to Issue 2.
Issue 2: File Execution Fails After IMA Appraisal Enforce Mode Is Enabled
After IMA appraisal enforce mode is enabled, if the content or extended attributes of a file configured with IMA policies are incorrect (for example, they do not match the imported digest list), file access may be denied. Common causes include:
- The digest list was not successfully imported (refer to Issue 1 for details).
- The file content or attributes have been tampered with.
For scenarios where file execution fails, first ensure that the digest list file has been successfully imported into the kernel. Check the number of digest lists to determine the import status:
cat /sys/kernel/security/ima/digests_count
Next, use the audit logs (default path: /var/log/audit/audit.log) to identify which file failed verification and the reason. A typical log output is as follows:
type=INTEGRITY_DATA msg=audit(1722811960.997:2967): pid=7613 uid=0 auid=0 ses=1 subj=unconfined_u:unconfined_r:haikang_t:s0-s0:c0.c1023 op=appraise_data cause=IMA-signature-required comm="bash" name="/root/test" dev="dm-0" ino=814424 res=0 errno=0UID="root" AUID="root"
After identifying the file that failed verification, compare it with the TLV digest list to determine the cause of tampering. For scenarios where extended attribute verification is not enabled, only compare the SHA256 hash value of the file with the IMA digest
entry in the TLV digest list. For scenarios where extended attribute verification is enabled, also compare the current file attributes with the extended attributes displayed in the TLV digest list.
Once the cause of the issue is determined, resolve it by restoring the file content and attributes or regenerating the digest list for the file, signing it, and importing it into the kernel.
Issue 3: Errors Occur During Packages Installation Across openEuler 22.03 LTS SP Versions After IMA Appraisal Mode Is Enabled
After IMA appraisal mode is enabled, installing packages from different SP versions of openEuler 22.03 LTS triggers the import of IMA digest lists. This process includes a signature verification step, where the kernel uses its certificates to verify the digest list signatures. Due to changes in signing certificates during the evolution of openEuler, backward compatibility issues may arise in certain cross-SP-version installation scenarios (there are no forward compatibility issues, meaning newer kernels can verify older IMA digest list files without problems).
You are advised to ensure that the following signing certificates are present in the current kernel:
# keyctl show %:.builtin_trusted_keys
Keyring
566488577 ---lswrv 0 0 keyring: .builtin_trusted_keys
383580336 ---lswrv 0 0 \_ asymmetric: openeuler <openeuler@compass-ci.com> b675600b
453794670 ---lswrv 0 0 \_ asymmetric: private OBS b25e7f66
938520011 ---lswrv 0 0 \_ asymmetric: openeuler <openeuler@compass-ci.com> fb37bc6f
If any certificates are missing, you are advised to upgrade the kernel to the latest version:
yum update kernel
openEuler 24.03 LTS and later versions include dedicated IMA certificates and support certificate chain verification, ensuring the certificate lifecycle covers the entire LTS version.
Issue 4: IMA Digest List Import Fails Despite Correct Signatures After IMA Digest List Appraisal Mode Is Enabled
The IMA digest list import process includes a verification mechanism. If a digest list fails signature verification during import, the digest list import functionality is disabled, preventing even correctly signed digest lists from being imported afterward. Check the dmesg logs for the following message to confirm if this is the cause:
# dmesg
ima: 0-metadata_list-compact-bash-5.1.8-6.oe2203sp1.x86_64 not appraised, disabling digest lists lookup for appraisal
If such a log is present, a digest list file with an incorrect signature was imported while IMA digest list appraisal mode was enabled, causing the functionality to be disabled. In this case, reboot the system and fix the incorrect digest list signature information.
Issue 5: Importing User-Defined IMA Certificates Fails in openEuler 24.03 LTS and Later Versions
Linux kernel 6.6 introduced additional field validation restrictions for importing certificates. Certificates imported into the IMA key ring must meet the following constraints (following the X.509 standard format):
- It must be a digital signature certificate, meaning the
keyUsage=digitalSignature
field must be set. - It must not be a CA certificate, meaning the
basicConstraints=CA:TRUE
field must not be set. - It must not be an intermediate certificate, meaning the
keyUsage=keyCertSign
field must not be set.
Issue 6: kdump Service Fails to Start After IMA Appraisal Mode Is Enabled
After IMA appraisal enforce mode is enabled, if the IMA policy includes the following KEXEC_KERNEL_CHECK
rule, the kdump service may fail to start:
appraise func=KEXEC_KERNEL_CHECK appraise_type=imasig
The reason is that in this scenario, all files loaded via kexec
must undergo integrity verification. As a result, the kernel restricts the loading of kernel image files by kdump to the kexec_file_load
system call. This can be enabled by modifying the /etc/sysconfig/kdump configuration file:
KDUMP_FILE_LOAD="on"
Additionally, the kexec_file_load
system call itself performs signature verification on the files. Therefore, the kernel image file being loaded must contain a valid secure boot signature, and the current kernel must include the corresponding verification certificate.