add config options for the persisted idevid and iak handles, passwords

[Isaac-Matthews]

Fixes #1549

Adds config options to the templates for the IDevID and IAK handles if the keys have been persisted, and their passwords if they are password protected.

These are the template changes for the Rust agent changes here PR 785.

[maugustosilva]

Given that keylime/rust-keylime#785 was already merged, I see no reason to delay the merging of this PR.

However, I do see an error on fedora-rawhide which is affecting all PRs. @kkaarreell I had a brief discussion with @ansasaki and he mentioned that perhaps we should no longer block on rawhide failures.

[kkaarreell]

However, I do see an error on fedora-rawhide which is affecting all PRs. @kkaarreell I had a brief discussion with @ansasaki and he mentioned that perhaps we should no longer block on rawhide failures.

We can either keep Rawhide tests running but ignore known failures or disable Rawhide tests completely. I would prefer to do the earlier since those Rawhide failures may give us early warning, the issue would most likely appear in Fedora stable later.

However, would you know why tests are failing in this particular case? In the 2nd test I see

:: [ 10:42:13 ] :: [  BEGIN   ] :: Running 'rpmsign --addsign --signfiles --fskpath=/etc/keys/privkey_evm.pem /root/rpmbuild/RPMS/noarch/rpm-ima-sign-test-1-1.noarch.rpm'
hash(sha384): 562eb1111ef3e3c2ec9c60e53b27af259ff984f31a804d97bfd49df13e843128
sign_hash_v2: signing failed: (invalid digest length) in EVP_PKEY_sign
openssl: error:1C8000A6:Provider routines::invalid digest length
error: sign_hash failed
error: signFile failed
/root/rpmbuild/RPMS/noarch/rpm-ima-sign-test-1-1.noarch.rpm:

which might be a but in the package or in the test, I will look into it.
However, for /compatibility/basic-attestation-on-localhost-api-version-bump I do not see the issue there. The tests expects the verifier to log 'API version updated' but this is not happening. The agent is using v2.1, the verifier seems to use 2.2. Also, when starting agent with v2.1 again the failure is expected but it is not happening. It behaves like if the verifier would be using also 2.1 but the log says:

keylime.verifier - INFO - Current API version 2.2

@ansasaki Would you know what's happening here?

[ansasaki]

However, for /compatibility/basic-attestation-on-localhost-api-version-bump I do not see the issue there. The tests expects the verifier to log 'API version updated' but this is not happening. The agent is using v2.1, the verifier seems to use 2.2. Also, when starting agent with v2.1 again the failure is expected but it is not happening. It behaves like if the verifier would be using also 2.1 but the log says:

keylime.verifier - INFO - Current API version 2.2

@ansasaki Would you know what's happening here?

This is weird. What the test does is:

1. Backup the installed agent binary (from the log keylime-agent-rust-0.2.5-1.20240508132448021528.master.4.gc91fba3.fc41.x86_64 was installed)
2. Compile the "old" version and replace the binary
3. Run the old version to register the old API
4. Stop the agent, restore the original binary from backup, and run to trigger the bump detection
5. Stop the agent, replace the binary again with the old version, and run to check that it does not allow rollback

Looking into the logs, the "old" version was compiled and run correctly with the old API version. Then, the new binary should be restored from the backup and run with then new API version to trigger the bump detection, but it is still using the API version 2.1.

Since the preinstalled version is correct, it should be running with the new API version after restoring the backup. My suspicion is that maybe the preinstalled binary, for some reason, is in another place in Rawhide (not in /usr/bin/keylime_agent). I'll investigate.

[kkaarreell]

I have tracked all these issue down to different packages. I believe it is safe to merge this PR.
The rust agent API related issue is being addressed in RedHat-SP-Security/keylime-tests#588,
there are more issues to fix in Rawhide though.

[ansasaki]

Just a note that the changes here are only valid while the version 7.11.0 is not released since it would release the config version 2.3.

If this PR is not included in 7.11.0, the correct approach is to introduce a new config version 2.4

@maugustosilva FYI

[maugustosilva]

@kkaarreell I have no fundamental opposition on keep rawhide running in an "advisory" capacity (i.e., a failure there does not block anything). I will just have to formalize it at our next monthly meeting. Thanks.

[kkaarreell]

@kkaarreell I have no fundamental opposition on keep rawhide running in an "advisory" capacity (i.e., a failure there does not block anything). I will just have to formalize it at our next monthly meeting. Thanks.

OK. This is a "risk" of running e2e tests, they are dependencies outside of the keylime scope and any of them can introduce a regression. This time rpm (btw, https://bugzilla.redhat.com/show_bug.cgi?id=2291183 has a fix already), usually it is selinux-policy (we ignore AVCs on Rawhide) or some tpm2-* package. Rawhide is just a bit more exposed but it may happen on other Fedoras or CS as well. Anyway, I think things are on a good track and we should see Rawhide tests green again in a few days.