CREDS_CHECK hook with incorrect credentials

[robertosassu]

Based on the discussion here (https://lkml.org/lkml/2025/4/10/1002), we need to address the fact that the VFS no longer recalculates the credentials at each step of the binary handler search. Thus, IMA would not see for example the updated euid/egid because that is calculated later after the interpreter is found.

Paul Moore suggested to have an IMA-specific way of getting the information it was getting before.

[robertosassu]

Proposing robertosassu/linux@5de00f9

[robertosassu]

Test results (measurement)

[root@fedora ~]# echo "measure func=CREDS_CHECK euid=0" > /sys/kernel/security/ima/policy

(in another terminal)
[roberto@fedora ~]$ sudo ls
[sudo] password for roberto:

Without the patch:

[root@fedora ~]# cat /sys/kernel/security/ima/ascii_runtime_measurements
10 45528809b9564fd71101291596b6ab7b5477328e ima-ng sha256:04790e71a72b279ec6900be187eac3597177ded490d5feb09e527b1027fbf7be boot_aggregate
10 7d80405042183ad1cdaaca7bc3dfe0912884993b ima-ng sha256:26c7ec7ec9b4863d7fbb25cc653f07569e0686d0e36d37d030c305731c8bf99d /usr/bin/ls
10 6a4e00d5b7ec654a7eed341988f975e24a9aac6d ima-ng sha256:59dd76a17c003c88dd01d02dc29e4cfb4dc6e65090bf5497d306b17612a4c2e0 /usr/bin/cat

sudo is not measured

With the patch:

[root@fedora ~]# cat /sys/kernel/security/ima/ascii_runtime_measurements
10 45528809b9564fd71101291596b6ab7b5477328e ima-ng sha256:04790e71a72b279ec6900be187eac3597177ded490d5feb09e527b1027fbf7be boot_aggregate
10 f3f3a2d0dad53dc8eeaa974d032311d0dc5507de ima-ng sha256:1de4cb1b4083194734576495b75bc65196de30b8c9508ceae22ed0b6fbc8f7f1 /usr/libexec/nm-dispatcher
10 825bd17941f5dfddf2e9721fcc3391b7811f6179 ima-ng sha256:26c35519bf0aeef477c0775f254efbc520e79530f5f678e630cf50182f142d1a /usr/bin/bash
10 464ce2e5832a795fd02cfc0708d41ff2129d08ab ima-ng sha256:fa9ecd30f429d6a43aacd419441841e9f8d3f34a94d243e5b29d3da71ed5f56d /usr/bin/mkdir
10 bc6e311e3df1f9813bf6dee12eec883796ac9aaa ima-ng sha256:3f66a089050235398ee2de1a65b859760150417385b56f70de4fc586bd841b22 /usr/bin/chronyc
10 e06425c0df69d66a85bd83ce63055c6a6e7eee1f ima-ng sha256:5221d69e5eff19b57e1d285aa0beebd8cc89762811763c87be4a05ca4389643f /usr/bin/sudo
10 7d80405042183ad1cdaaca7bc3dfe0912884993b ima-ng sha256:26c7ec7ec9b4863d7fbb25cc653f07569e0686d0e36d37d030c305731c8bf99d /usr/bin/ls
10 6a4e00d5b7ec654a7eed341988f975e24a9aac6d ima-ng sha256:59dd76a17c003c88dd01d02dc29e4cfb4dc6e65090bf5497d306b17612a4c2e0 /usr/bin/cat

sudo is measured

[robertosassu]

Test results (appraisal)

[root@fedora ~]# evmctl ima_sign --key /mnt/repos/linux/certs/signing_key.pem /usr/libexec/nm-dispatcher
hash(sha256): 1de4cb1b4083194734576495b75bc65196de30b8c9508ceae22ed0b6fbc8f7f1
keyid 19a1fd75 (from /mnt/repos/linux/certs/signing_key.pem)
evm/ima signature: 111 bytes
03020419a1fd750067306502310096e156199c9beab6151eedd84fa7e604bd37e47228b5554ff2275d4d597b1454e55238927e6335baeac3ca846df77eb502301b0023a9a4859b9f0b28efd298cffd7c2a5fca50e2a6ff331b58c11e6521b56b36151aa42e4affca549e07cb0017224c
<Repeated for all the binaries in the measurement list shown in the previous comment (except for sudo)>

[root@fedora ~]# echo "appraise func=CREDS_CHECK euid=0" > /sys/kernel/security/ima/policy

Without the patch:

(in another terminal)
[roberto@fedora ~]$ sudo ls
[sudo] password for roberto:

[root@fedora ~]# journalctl -axb|grep INTEGRITY
Sep 25 11:41:19 fedora audit: INTEGRITY_POLICY_RULE action=appraise func=CREDS_CHECK euid=0 res=1
Sep 25 11:41:19 fedora audit[734]: INTEGRITY_STATUS pid=734 uid=0 auid=0 ses=1 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 op=policy_update cause=completed comm="bash" res=1 errno=0

sudo is not appraised (no error)

With the patch:

(in another terminal)
[roberto@fedora ~]$ sudo ls
-bash: /usr/bin/sudo: Permission denied

[root@fedora ~]# journalctl -axb|grep INTEGRITY
Sep 25 11:35:29 fedora audit: INTEGRITY_POLICY_RULE action=appraise func=CREDS_CHECK euid=0 res=1
Sep 25 11:35:29 fedora audit[740]: INTEGRITY_STATUS pid=740 uid=0 auid=0 ses=1 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 op=policy_update cause=completed comm="bash" res=1 errno=0
Sep 25 11:35:32 fedora audit[846]: INTEGRITY_DATA pid=846 uid=1000 auid=1000 ses=3 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 op=appraise_data cause=missing-hash comm="bash" name="/usr/bin/sudo" dev="sda3" ino=5623 res=0 errno=0

sudo is appraised and found unsigned

After signing sudo:

[root@fedora ~]# evmctl ima_sign --key /mnt/repos/linux/certs/signing_key.pem /usr/bin/sudo
hash(sha256): 5221d69e5eff19b57e1d285aa0beebd8cc89762811763c87be4a05ca4389643f
keyid 19a1fd75 (from /mnt/repos/linux/certs/signing_key.pem)
evm/ima signature: 110 bytes
03020419a1fd7500663064023050cc5ccd311801960594c0a6fc7fc76907d41dca449d10c742606b5869893e13264e2890c8181a7bfbc2bf5063ea12da0230511b175a3551919df6c015239179e971aaa1c1af55616b71420fdaf50be64ee83c4b793c96e2fba19e16736ec0044602

(in another terminal)
[roberto@fedora ~]$ sudo ls
[sudo] password for roberto:

sudo now works

[mimizohar]

Roberto, thank you for the analysis and example. Commit d906c10 ("IMA: Support using new creds in appraisal policy") , which added the creds checking to the bprm_check hook was actually interested in the credentials of the end target application. From the patch description, it is clear that the new creds check wasn't a replacement for bprm_check hook, but an addition. The existing bprm_check rules would continue to work as normal. The new creds check was in fact being used to limit the number of applications being measured/appraised.

For this reason, the "sudo" example with a single CREDS_CHECK rule describing the problem is not a good example, as it would have been measured/appraised based on the original bprm_check policy rules. It also explains why the issue wasn't detected up to this point. Do you have an example of a creds change which would not have been detected by bprm_check policy rules?

At this point, I'm not sure this should be classified as a regression or as a new feature. If you feel that the CREDS_CHECK policy rule should not be dependent on also having a BPRM_CHECK policy rule, it could be upstreamed as a feature.
The patch itself looks fine. The patch description would need to be updated. I'm also concerned with the existing bprm_creds_from_file() hook comment, which says "Compute brpm->cred based upon the final binary".

[robertosassu]

Patch sent to the mailing lists: https://lkml.org/lkml/2025/10/8/473