IMA: Deferred measurement of keys

PATCH Superseded Lakshmi Ramasubramanian 2 participants 10 messages Dec 18, 2019 – Dec 20, 2019

Subsystems (5)

Security (LSM) Keys-trusted Keys/keyrings Integrity measurement architecture (IMA) +1 more subsystems

lore

Share & tools

lore

Lakshmi Ramasubramanian

author

2019-12-18 16:44 UTC #0 lore raw

v5 cover IMA: Deferred measurement of keys

This patchset extends the previous version[1] by adding support for deferred processing of keys.

With the patchset referenced above, the IMA subsystem supports measuring asymmetric keys when the key is created or updated. But keys created or updated before a custom IMA policy is loaded are currently not measured. This includes keys added to, for instance, .builtin_trusted_keys which happens early in the boot process.

This change adds support for queuing keys created or updated before a custom IMA policy is loaded. The queued keys are processed when a custom policy is loaded. Keys created or updated after a custom policy is loaded are measured immediately (not queued).

If the kernel is built with both CONFIG_IMA and CONFIG_ASYMMETRIC_PUBLIC_KEY_SUBTYPE enabled then the IMA policy must be applied as a custom policy. Not providing a custom policy in the above configuration would result in asymmeteric keys being queued until a custom policy is loaded. This is by design.

[1] https://lore.kernel.org/linux-integrity/[email protected]/

Testing performed:

* Booted the kernel with this change.
* Added .builtin_trusted_keys in "keyrings=" option in the IMA policy and verified the keys added to this keyring are measured.
* Specified only func=KEY_CHECK and not "keyrings=" option, and verified the keys added to builtin_trusted_keys keyring are processed.
* Added keys at runtime and verified they are measured if the IMA policy permitted.
=> For example, added keys to .ima keyring and verified.

Changelog:

=> Removed temp keys list in ima_process_queued_keys()

=> Check and set ima_process_keys flag with mutex held.

=> Defined ima_process_keys flag to be static. => Set ima_process_keys with ima_keys_mutex held. => Added a comment in ima_process_queued_keys() function
to state the use of temporary list for keys.

=> Rebased the changes to v5.5-rc1
=> Updated function names, variable names, and code comments
to be less verbose.

=> Code cleanup

=> Based changes on v5.4-rc8
=> The following patchsets should be applied in that order

     https://lore.kernel.org/linux-integrity/[email protected]
     https://lore.kernel.org/linux-integrity/[email protected]/

=> Added functions to queue and dequeue keys, and process
the queued keys when custom IMA policies are applied.

Lakshmi Ramasubramanian (2):
IMA: Define workqueue for early boot key measurements
IMA: Call workqueue functions to measure queued keys

 security/integrity/ima/ima.h                 |  15 +++
 security/integrity/ima/ima_asymmetric_keys.c | 123 +++++++++++++++++++
 security/integrity/ima/ima_policy.c          |   3 +
 3 files changed, 141 insertions(+)

Signature · 1 line

2.17.1

Lakshmi Ramasubramanian

author

2019-12-18 16:44 UTC #1 lore raw

PATCH v5 1/2 IMA: Define workqueue for early boot "key" measurements

Measuring keys requires a custom IMA policy to be loaded. Keys created or updated before a custom IMA policy is loaded should be queued and the keys should be processed after a custom policy is loaded.

This patch defines workqueue for queuing keys when a custom IMA policy has not yet been loaded.

A flag namely ima_process_keys is used to check if the key should be queued or should be processed immediately.

Signed-off-by Lakshmi Ramasubramanian <[email protected]>

---
 security/integrity/ima/ima.h                 |  15 +++
 security/integrity/ima/ima_asymmetric_keys.c | 115 +++++++++++++++++++
 2 files changed, 130 insertions(+)

security/integrity/ima/ima.h +15 -0

index f06238e41a7c..97f8a4078483 100644
@@ -205,6 +205,21 @@ extern const char *const func_tokens[];
 
 struct modsig;
 
+#ifdef CONFIG_ASYMMETRIC_PUBLIC_KEY_SUBTYPE
+/*
+ * To track keys that need to be measured.
+ */
+struct ima_key_entry {
+	struct list_head list;
+	void *payload;
+	size_t payload_len;
+	char *keyring_name;
+};
+void ima_process_queued_keys(void);
+#else
+static inline void ima_process_queued_keys(void) {}
+#endif /* CONFIG_ASYMMETRIC_PUBLIC_KEY_SUBTYPE */
+
 /* LIM API function definitions */
 int ima_get_action(struct inode *inode, const struct cred *cred, u32 secid,
 		   int mask, enum ima_hooks func, int *pcr,

security/integrity/ima/ima_asymmetric_keys.c +115 -0

121 lines not on this page · raw message

Signature · 1 line

2.17.1

Mimi Zohar

maintainer

2019-12-19 13:11 UTC #2 lore raw

Re: [PATCH v5 1/2] IMA: Define workqueue for early boot "key" measurements

Quoted 29 lines · Lakshmi Ramasubramanian

security/integrity/ima/ima_asymmetric_keys.c +29 -0

+/*
+ * ima_process_queued_keys() - process keys queued for measurement
+ *
+ * This function sets ima_process_keys to true and processes queued keys.
+ * From here on keys will be processed right away (not queued).
+ */
+void ima_process_queued_keys(void)
+{
+	struct ima_key_entry *entry, *tmp;
+	bool process = false;
+
+	if (ima_process_keys)
+		return;
+
+	/*
+	 * Since ima_process_keys is set to true, any new key will be
+	 * processed immediately and not be queued to ima_keys list.
+	 * First one setting the ima_process_keys flag to true will
+	 * process the queued keys.
+	 */
+	mutex_lock(&ima_keys_mutex);
+	if (!ima_process_keys) {
+		ima_process_keys = true;
+		process = true;
+	}
+	mutex_unlock(&ima_keys_mutex);
+
+	if (!process)
+		return;

security/integrity/ima/ima_asymmetric_keys.c line 131

Quoted 10 lines

security/integrity/ima/ima_asymmetric_keys.c +10 -0

+
+	list_for_each_entry_safe(entry, tmp, &ima_keys, list) {
+		process_buffer_measurement(entry->payload, entry->payload_len,
+					   entry->keyring_name, KEY_CHECK, 0,
+					   entry->keyring_name);
+		list_del(&entry->list);
+		ima_free_key_entry(entry);
+	}
+}
+

Getting rid of the temporary list is definitely a big improvement. As James suggested, using test_and_set_bit() and test_bit() would improve this code even more. I think, James correct me if I'm wrong, you would be able to get rid of both the mutex and "process".

Mimi

Quoted 3 lines

/**
* ima_post_key_create_or_update - measure asymmetric keys
* @keyring: keyring to which the key is linked to

Lakshmi Ramasubramanian

author

2019-12-19 16:55 UTC #3 lore raw

Re: [PATCH v5 1/2] IMA: Define workqueue for early boot "key" measurements

Quoted 7 lines · Mimi Zohar

Getting rid of the temporary list is definitely a big improvement. As James suggested, using test_and_set_bit() and test_bit() would improve this code even more. I think, James correct me if I'm wrong, you would be able to get rid of both the mutex and "process".
Mimi

I am not sure if the mutex can be removed.

In ima_queue_key() we need to test the flag and add the key to the list as an atomic operation:

if (!test_bit())
insert_key_to_list

Suppose the if condition is true, but before we could insert the key to the list, ima_process_queued_keys() runs and processes queued keys we'll add the key to the list and never process it.

Is there an API in the kernel to test and add an entry to a list atomically?

thanks,
-lakshmi

Mimi Zohar

maintainer

2019-12-20 12:53 UTC #4 lore raw

Re: [PATCH v5 1/2] IMA: Define workqueue for early boot "key" measurements

Quoted 8 lines · Lakshmi Ramasubramanian

I am not sure if the mutex can be removed.
In ima_queue_key() we need to test the flag and add the key to the list as an atomic operation:
if (!test_bit())
insert_key_to_list

Quoted 6 lines

Suppose the if condition is true, but before we could insert the key to the list, ima_process_queued_keys() runs and processes queued keys we'll add the key to the list and never process it.
Is there an API in the kernel to test and add an entry to a list atomically?

Ok, using test_and_set_bit() and test_bit() only helps, if we can get rid of the mutex. I'll queue these patches.

thanks,

Mimi

Lakshmi Ramasubramanian

author

2019-12-18 16:44 UTC #5 lore raw

PATCH v5 2/2 IMA: Call workqueue functions to measure queued keys

In reply to Lakshmi Ramasubramanian

Measuring keys requires a custom IMA policy to be loaded. Keys should be queued for measurement if a custom IMA policy is not yet loaded. Keys queued for measurement, if any, should be processed when a custom IMA policy is loaded.

This patch updates the IMA hook function ima_post_key_create_or_update() to queue the key if a custom IMA policy has not yet been loaded. And, ima_update_policy() function, which is called when
a custom IMA policy is loaded, is updated to process queued keys.

Sample "key" measurement rule in the IMA policy:

measure func=KEY_CHECK uid=0 keyrings=.ima|.builtin_trusted_keys template=ima-buf

If the kernel is built with one or more built-in trusted certificates, IMA measurement should list all the keys imported from those certificates.

Display "key" measurement in the IMA measurement list:

cat /sys/kernel/security/ima/ascii_runtime_measurements

10 faf3...e702 ima-buf sha256:27c915b8ddb9fae7214cf0a8a7043cc3eeeaa7539bcb136f8427067b5f6c3b7b .builtin_trusted_keys 308202863082...4aee

Verify "key" measurement data for a key added to ".builtin_trusted_keys" keyring:

The output of the above command should match the template hash of the first "key" measurement entry in the IMA measurement list for the key added to ".builtin_trusted_keys" keyring.

The file namely "btk-cert.der" generated by the above command should be a valid x509 certificate (in DER format) and should match the one that was used to import the key to the ".builtin_trusted_keys" keyring. The certificate file can be verified using openssl tool.

Signed-off-by Lakshmi Ramasubramanian <[email protected]>

---
 security/integrity/ima/ima_asymmetric_keys.c | 8 ++++++++
 security/integrity/ima/ima_policy.c          | 3 +++
 2 files changed, 11 insertions(+)

security/integrity/ima/ima_asymmetric_keys.c +8 -0

index d520a67180d8..4124f10ff0c2 100644
@@ -145,6 +145,8 @@ void ima_post_key_create_or_update(struct key *keyring, struct key *key,
 				   const void *payload, size_t payload_len,
 				   unsigned long flags, bool create)
 {
+	bool queued = false;
+
 	/* Only asymmetric keys are handled by this hook. */
 	if (key->type != &key_type_asymmetric)
 		return;

@@ -152,6 +154,12 @@ void ima_post_key_create_or_update(struct key *keyring, struct key *key,
 	if (!payload || (payload_len = 0))
 		return;
 
+	if (!ima_process_keys)
+		queued = ima_queue_key(keyring, payload, payload_len);
+
+	if (queued)
+		return;
+
 	/*
 	 * keyring->description points to the name of the keyring
 	 * (such as ".builtin_trusted_keys", ".ima", etc.) to

security/integrity/ima/ima_policy.c +3 -0

index a4dde9d575b2..04b9c6c555de 100644
@@ -807,6 +807,9 @@ void ima_update_policy(void)
 		kfree(arch_policy_entry);
 	}
 	ima_update_policy_flag();
+
+	/* Custom IMA policy has been loaded */
+	ima_process_queued_keys();
 }
 
 /* Keep the enumeration in sync with the policy_tokens! */

Signature · 1 line

2.17.1

Mimi Zohar

maintainer

2019-12-20 19:01 UTC #6 lore raw

In reply to Lakshmi Ramasubramanian

Quoted 14 lines · Lakshmi Ramasubramanian

This patchset extends the previous version[1] by adding support for deferred processing of keys.
With the patchset referenced above, the IMA subsystem supports measuring asymmetric keys when the key is created or updated. But keys created or updated before a custom IMA policy is loaded are currently not measured. This includes keys added to, for instance, .builtin_trusted_keys which happens early in the boot process.
This change adds support for queuing keys created or updated before a custom IMA policy is loaded. The queued keys are processed when a custom policy is loaded. Keys created or updated after a custom policy is loaded are measured immediately (not queued).

Quoted 5 lines

If the kernel is built with both CONFIG_IMA and CONFIG_ASYMMETRIC_PUBLIC_KEY_SUBTYPE enabled then the IMA policy must be applied as a custom policy. Not providing a custom policy in the above configuration would result in asymmeteric keys being queued until a custom policy is loaded. This is by design.

I didn't notice the "This is by design" here, referring to the memory never being freed. "This is by design" was suppose to refer to requiring a custom policy for measuring keys.

For now, these two patches are queued in the next-integrity-testing branch, but I would appreciate your addressing not freeing the memory associated with the keys, if a custom policy is not loaded.

Please note that I truncated the 2/2 patch description, as it repeats the existing verification example in commit ("2b60c0ecedf8 IMA: Read keyrings= option from the IMA policy").

thanks,

Mimi

Lakshmi Ramasubramanian

author

2019-12-20 19:24 UTC #7 lore raw

On 12/20/2019 11:01 AM, Mimi Zohar wrote:

Hi Mimi,

Quoted 14 lines

Quoted 5 lines
If the kernel is built with both CONFIG_IMA and CONFIG_ASYMMETRIC_PUBLIC_KEY_SUBTYPE enabled then the IMA policy must be applied as a custom policy. Not providing a custom policy in the above configuration would result in asymmeteric keys being queued until a custom policy is loaded. This is by design.
I didn't notice the "This is by design" here, referring to the memory never being freed. "This is by design" was suppose to refer to requiring a custom policy for measuring keys.
For now, these two patches are queued in the next-integrity-testing branch, but I would appreciate your addressing not freeing the memory associated with the keys, if a custom policy is not loaded.

Quoted 8 lines

Please note that I truncated the 2/2 patch description, as it repeats the existing verification example in commit ("2b60c0ecedf8 IMA: Read keyrings= option from the IMA policy").
thanks,
Mimi

Sure - I am fine with truncating the 2/2 patch description. Thanks for doing that.

Regarding "Freeing the queued keys if custom policy is not loaded":

Shall I create a new patch set to address that and have that be reviewed independent of this patch set?

Like you'd suggested earlier, we can wait for a certain time, after IMA is initialized, and free the queue if a custom policy was not loaded.

Please let me know.

thanks,
-lakshmi

Mimi Zohar

maintainer

2019-12-20 19:36 UTC #8 lore raw

Quoted 27 lines · Lakshmi Ramasubramanian

On 12/20/2019 11:01 AM, Mimi Zohar wrote:
Hi Mimi,
Quoted 14 lines
Quoted 5 lines
If the kernel is built with both CONFIG_IMA and CONFIG_ASYMMETRIC_PUBLIC_KEY_SUBTYPE enabled then the IMA policy must be applied as a custom policy. Not providing a custom policy in the above configuration would result in asymmeteric keys being queued until a custom policy is loaded. This is by design.
I didn't notice the "This is by design" here, referring to the memory never being freed. "This is by design" was suppose to refer to requiring a custom policy for measuring keys.
For now, these two patches are queued in the next-integrity-testing branch, but I would appreciate your addressing not freeing the memory associated with the keys, if a custom policy is not loaded.
Quoted 8 lines
Please note that I truncated the 2/2 patch description, as it repeats the existing verification example in commit ("2b60c0ecedf8 IMA: Read keyrings= option from the IMA policy").
thanks,
Mimi

Quoted 7 lines

Sure - I am fine with truncating the 2/2 patch description. Thanks for doing that.
Regarding "Freeing the queued keys if custom policy is not loaded":
Shall I create a new patch set to address that and have that be reviewed independent of this patch set?

If it is just a single additional patch, feel free to post it without a cover letter.

Quoted 3 lines

Like you'd suggested earlier, we can wait for a certain time, after IMA is initialized, and free the queue if a custom policy was not loaded.

Different types of systems vary in boot time, but perhaps a certain amount of time after IMA is initialized would be consistent. This would need to work for IoT devices/sensors to servers.

Mimi

Lakshmi Ramasubramanian

author

2019-12-20 20:50 UTC #9 lore raw

Quoted 6 lines · Mimi Zohar

Quoted 3 lines
Shall I create a new patch set to address that and have that be reviewed independent of this patch set?
If it is just a single additional patch, feel free to post it without a cover letter.

Sure

Quoted 10 lines

Quoted 3 lines
Like you'd suggested earlier, we can wait for a certain time, after IMA is initialized, and free the queue if a custom policy was not loaded.
Different types of systems vary in boot time, but perhaps a certain amount of time after IMA is initialized would be consistent. This would need to work for IoT devices/sensors to servers.
Mimi

Yes - I agree.

thanks,
-lakshmi