Potential IMA Signing Bug

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Linux Kernel]     [Linux Kernel Hardening]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux SCSI]

  Powered by Linux