Discussion: Learning the keys from the IMA log and using them for signature verification

With an IMA policy rule like measure func=KEY_CHECK keyrings=.ima|.builtin_trusted_keys the IMA log starts reporting the keys that were loaded onto the respective keyrings. An allowlist could now be used by the verifier to approve the hashes of keys for the various keyrings and the verifier could then learn which keys to use for signature verification since the raw key bytes of the x509 cert in DER format are in the last column of the ima-buf entries in the log. Currently all the keys to be used by the verifier have to be passed via the tenant tool alongside the allowlist and exclude list. If one was to strongly manage the hashes in the allowlist then one could rely on the learning of the keys from the IMA log.

10 113dd04eb569de6bd1ed9007f5c0da18dd8673dc ima-sig sha256:bc70d24e63213dfd51024fc6b7b0f65c558ce799362b56c9ceef5009e8cc0625 boot_aggregate 
10 ba5fc1e406942fda0ef06f48eb1308c730d01784 ima-buf sha256:c3e21842f12fb0d9dfc4823d242016434419e2cb95a9574bf2bbb34aed2e9240 .builtin_trusted_keys 308205b33082039ba003020102021440bff914a88bab455339fe9af9f42a10694cc961300d06092a864886f70d01010d05003063310f300d060355040a0c064665646f72613122302006035504030c194665646f7261206b65726e656c207369676e696e67206b6579312c302a06092a864886f70d010901161d6b65726e656c2d7465616d406665646f726170726f6a6563742e6f72673020170d3231303631323138323532355a180f32313231303531393138323532355a3063310f300d060355040a0c064665646f72613122302006035504030c194665646f7261206b65726e656c207369676e696e67206b6579312c302a06092a864886f70d010901161d6b65726e656c2d7465616d406665646f726170726f6a6563742e6f726730820222300d06092a864886f70d01010105000382020f003082020a0282020100c900d3d472455835f39e0b6a87a4590c7a329402bdc53f746cc266fc5dce513174826a1a82306ce182283c0441210a83244a448c4e0b362a1e212195e98ad3e9a6172923e397fd94e9ffbfabba5e5bdf0e27bb33f96b73499d1a6a4ba05e9d00b157bf5c81df6d3d383985d1891812529452f07f8e544b92c0d490ec91c203f0d7b4ede124522bfbc6fcac4558e806311e5601fe0aef2f5a5a7121de14afcb6eedba9442771d0121bf2fb4a19d758b5e9d80b746edd205771c51e963147e818eb81fd353fa1e81ae61afa7475e015f048b87950e11b7a01371b8207f3057ecb47dcaf1ba820b9b1a199f1fcaff691d01f90d6b453e2a232a34b2d06cc1d4b0ad05e5fa2b68d783857b514c881cd11f03bd0fe2588b6a4f936d46f371beb70aa123a1b79121b4cf92b801d19ae0772e256c7cbdebf032b4595a9ef3bea3a50c40fb5f61afb708b9f9eb5307d3a8dc082e9a975b4071dfd5bd0f0ef862a14793b4203d9c9fa546e4aef407b046478e5899e85ef02c443ad89815b740a61e60f43a3020f38a9acb9fde8af33f23f68c4aff0e555274877b582eae86d7a0a79c06d466073e456b97cc530aad5d4d01d48cfc0c0e3bf0164697d8b1dbbe2d0bd31b8ec6cbbf992016c37f57eb306b05be8440d71521137e05a62d64cbbeeba4d83c4152c7e9f55915d06e9b2609c9b2e28c2683641e1756f1b421ff4c1e6b56259c790203010001a35d305b300c0603551d130101ff04023000300b0603551d0f040403020780301d0603551d0e04160414cf9d8130ab846c340f684c206fd08e27eb474371301f0603551d23041830168014cf9d8130ab846c340f684c206fd08e27eb474371300d06092a864886f70d01010d0500038202010058b087dd1a630549bed936afbe034a4ae1905e5d07590558293eb8dd531a352a83fe520cf1d5429c5755009bf7b7f61ee3d56c9a6d47d9128908851beea3c14ac00e2e8328b6c935758c7f397142030e3d987314019e8e9d8822e4f578fdf6e50e26a0fa4ec66146719afb378026c112e3c2dcb653c8481d8f49a94359c61596dea0c09bc242b0c0568538da0b80d27fb69bf81561e29131e3ebba6d6afd9c307cc85ab96d405ac99350ea04fa09f45e7fb6ce6fa5d295e4d26774619f74a3347f1b1ac52ff6622458741f0f71d2f3047bff9bfa9f5ae14f2b0084deefdf227d5750e9f421c9ee830604de9042f6e1faf7fe65e624549c6ccf1dc6a7bc66fa05a17fc5e5f86d4cdd530de523d1a5f757ccba1d7c09362923684618763b24222feb44b7fda4dc4f19259636a8a0d32e9ebd745203b3cc0be4ef95531513b3a6f028cb46975e1beb79f290e5396d6aca20d113e15daa7bce55cb17d73b48cacbcc3a2af5c3fb4a25557ba9f8791089c6104b0101b5c23f0a02f1a360403f35dea721e26751990d5b0bca33b63b5a376eb41f2f1a798ddc9e8fbb3c450d531e33a43fc996c4509e52e8f090486c9cc3d2be682c517e4ce9a203ad2ee911422a0870817bfa55e6393171eef3d567dd3fef48d46800bbbb9c0295a248dc7ffa1d3d762573c3d9dd40fbc45144930014853955460fc5f21465c37bc9dfd411a8b9052e
10 5d3dda549953356847a539ea45591d2595e1d7a7 ima-buf sha256:9e10813f8c361d58cafe9d4640f39641d87860ff60bccd27302cd9e216e5db64 .builtin_trusted_keys 30820313308201fba003020102021444a7161f6e2f1e31d35400aecbf0e456d97f223d300d06092a864886f70d01010b050030193117301506035504030c0e54657374696e672d5253412d4341301e170d3231303333313137333833325a170d3331303332393137333833325a30193117301506035504030c0e54657374696e672d5253412d434130820122300d06092a864886f70d01010105000382010f003082010a0282010100b699d0ccdfd68d820fc8f96ad72904d1134a945e4824fa1477c95fd9131187a0f7f2e3e4f962c6f57949a715ad1003dff1c999d505a989d3df3fc7d6376fea7423307e825b01e6184e87dfa58637eec62df213cd0752122d8292ef45cd1c8884f269c79d60f51e1c5a07e206a9e91344df8e3352466e3e554ff99df478ab66514a3017fd73b962468679e8bde7f898c60e7c4104ab91347614f7efe97651b1e1e7c90531665f87ac53a51b8e8674f85047fd69e4a6d1cb748526b6dff0ef7ab0c87ee220240922d3b1688c6f0d92fbee9df5e714c6ebb1d87a6055ab8f0461a4e4686d06e6d6ae15bf40ee29a83eb88e0a68aa6d697f1ec19a99eb59eeb4a2fb0203010001a3533051301d0603551d0e041604147f6eab4588dbbde820e73466c18dff58e2893913301f0603551d230418301680147f6eab4588dbbde820e73466c18dff58e2893913300f0603551d130101ff040530030101ff300d06092a864886f70d01010b050003820101001364196df61760565bcaf16a16a26b6044d920d5713534331a171c78b0b057ee53ee4679ed739e69d0b9ce420e33492dafb5032fceb35a2cc3cc6ac2fc23c4973efcae0235b23d36940650a8b60cbd69a456d9942fef36a5ba2114fc9fdb632418cee200aa1bfff5294621504c38c7d78476bf9845c19ad47e1ee23404b2e8e8c77b31bbb9201db69e4dc49f698416929a22ec1369e2f8f052ba3489fafe4568b33b1088d24694543c4c6ea33b02958b4ed76264d36239c154624a71c34e23c58c93df8e3751ca2c4b65179f9bc26dc5927a1416628542649d4944da170ec93e71d7788685d9661a2bb653d79673a0b2774bd657ed8367f97c9f8f73254867ef

[THS-on]

Using %keyring as a prefix for the old format should work because I think the other paths should be normally absolute.

I haven’t used it much so far, so I am not currently sure how it’s converted internally.

The current allowlist reader checks if it is a JSON object and otherwise converts it into one here: https://github.com/keylime/keylime/blob/6ffe92379ebde2577fd4b104f214734e16938cfc/keylime/ima.py#L241-L269

But then only the hashes are returned by process_allowlists which then is used by the validators. I think we should then change this to let all validators use the allowlist object directly and with add an option to the ima-ng validator to look either for key or file hashes.

[stefanberger]

PR #725 attempts to address the basic issue now of implementing an ima-ng validator validating keys to be loaded onto keyrings and the conversion of the flat allowlist holding keyring entries to the JSON representation.