I am wondering if the following behavior is a bug. My system is Debian Buster with Linux kernel v5.7.13 running on x86_64 Intel hardware. My kernel's configuration file has the following relevant security options (+ their dependencies) turned on: ``` CONFIG_INTEGRITY=y CONFIG_INTEGRITY_SIGNATURE=y CONFIG_INTEGRITY_ASYMMETRIC_KEYS=y CONFIG_INTEGRITY_AUDIT=y CONFIG_IMA=y CONFIG_IMA_MEASURE_PCR_IDX=10 CONFIG_IMA_LSM_RULES=y CONFIG_IMA_NG_TEMPLATE=y CONFIG_IMA_DEFAULT_TEMPLATE="ima-ng" CONFIG_IMA_DEFAULT_HASH_SHA256=y CONFIG_IMA_DEFAULT_HASH="sha256" CONFIG_IMA_WRITE_POLICY=y CONFIG_IMA_READ_POLICY=y CONFIG_IMA_APPRAISE=y CONFIG_IMA_APPRAISE_BOOTPARAM=y CONFIG_IMA_MEASURE_ASYMMETRIC_KEYS=y # CONFIG_INTEGRITY_TRUSTED_KEYRING is not set # CONFIG_INTEGRITY_PLATFORM_KEYRING is not set CONFIG_IMA_QUEUE_EARLY_BOOT_KEYS=y CONFIG_EVM=y CONFIG_EVM_ATTR_FSUUID=y ``` and I updated GRUB to include `ima_appraise=fix` to the boot parameters. The policy I load looks like the following: ``` measure fowner=1000 appraise fowner=1000 appraise_type=imasig ``` To sign IMA hashes I load an x509 certificate onto root's `_ima` keyring via the following procedure (assume I have the file x509_ima.genkey as in the `evmctl` manpage): ``` root@deb:~# openssl req -new -nodes -utf8 -sha1 -days 36500 -batch \ > -x509 -config x509_ima.genkey \ > -outform DER -out x509_ima.der -keyout privkey_ima.pem Generating a RSA private key ......+++++ ....+++++ writing new private key to 'privkey_ima.pem' ----- root@deb:~# ima_id=`keyctl newring _ima @u` root@deb:~# cat x509_ima.der | keyctl padd asymmetric 'ima_cert' $ima_id 282969187 root@deb:~# keyctl show Session Keyring 727602364 --alswrv 0 0 keyring: _ses 17430979 --alswrv 0 65534 \_ keyring: _uid.0 822262864 --alswrv 0 0 \_ keyring: _ima 282969187 --als--v 0 0 \_ asymmetric: ima_cert ``` I have a simple executable, `hello`, that prints a simple "Hello world!" message. Using the matching private key of the x509 certificate above and `evmctl` I can hash and sign the executable: ``` user@deb:~$ sudo evmctl -v ima_sign --key /root/privkey_ima.pem hello hash: 4409ab55775b430524cf9c9bbe798a8213de740e evm/ima signature: 136 bytes 03020277de1ee90080696c392a74513afcff14208fe5c3a56b466a360becf7ca5aa11a502fd249fc7fa04d7631d9cd10602ba460c0133773ce3c33562e5e0d9770b3c0714f7b19bba4e4de0b88b12d512b7fa99732118de59a3fc098e1655d531a60a3c6052c434959ab739d740a5125f435bf0550eb57c9d09195816c6749a0ab6390196893ef9164 user@deb:~$ getfattr -m . -d hello # file: hello security.ima=0sAwICd94e6QCAaWw5KnRROvz/FCCP5cOla0ZqNgvs98paoRpQL9JJ/H+gTXYx2c0QYCukYMATN3POPDNWLl4Nl3CzwHFPexm7pOTeC4ixLVErf6mXMhGN5Zo/wJjhZV1TGmCjxgUsQ0lZq3OddApRJfQ1vwVQ61fJ0JGVgWxnSaCrY5AZaJPvkWQ= ``` After rebooting the machine in appraisal mode and loading the keys and policy I am unable to run the file as a user: ``` user@deb:~$ ./hello -bash: ./hello: Permission denied user@deb:~$ sudo dmesg | tail ... [ 78.593140] integrity: no _ima keyring: -126 [ 78.593343] audit: type=1800 audit(1599673725.324:11): pid=582 uid=1000 auid=1000 ses=1 subj==unconfined op=appraise_data cause=invalid-signature comm="bash" name="/home/user/hello" dev="sda1" ino=796088 res=0 ``` However, after running the file as root and switching back to my user profile I am able to run the file just fine due to the caching of the integrity status of the file. It seems to me that if a user doesn't have access to the key that signs a file, they should not be able to access the file. Is this a correct assessment of IMA's behavior? If this is a deliberate design choice, can you please explain why? Thank you for your time! Kind regards, Alexander Gaidis
