On Wed, 2020-09-09 at 13:13 -0600, Alexander Gaidis wrote: > 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. For some reason as a user you can't access the _ima keyring - "integrity: no _ima keyring: -126". Please create an additional signed file and try accessing that one as user, after accessing the original signed one succeeds. > > 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? A signed file is a signed file. Who signed it shouldn't make a difference. The public key needs to be on the appropriate keyring and accessible by the kernel. Have you tried automatically loading the public key(s) via dracut or systemd on boot? Does that make a difference? thanks, Mimi
