IMA: Deferred measurement of keys
Subsystems (5)
v3 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:
v3
=> 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.
v2
=> Rebased the changes to v5.5-rc1
=> Updated function names, variable names, and code comments
to be less verbose.
v1
=> Code cleanup
v0
=> 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 | 127 +++++++++++++++++++ security/integrity/ima/ima_policy.c | 3 + 3 files changed, 145 insertions(+)
Signature · 1 line
2.17.1
PATCH v3 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.
--- security/integrity/ima/ima.h | 15 +++ security/integrity/ima/ima_asymmetric_keys.c | 119 +++++++++++++++++++ 2 files changed, 134 insertions(+)
security/integrity/ima/ima.h +15 -0
@@ -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 +119 -0
125 lines not on this page · raw message
Signature · 1 line
2.17.1
Mimi Zohar
maintainerRe: [PATCH v3 1/2] IMA: Define workqueue for early boot "key" measurements
Quoted 16 lines
security/integrity/ima/ima_asymmetric_keys.c +16
-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; +LIST_HEAD (temp_ima_keys); + +if (ima_process_keys) +return ; + +/* +* To avoid holding the mutex when processing queued keys,
security/integrity/ima/ima_asymmetric_keys.c line 118
Quoted 10 lines
security/integrity/ima/ima_asymmetric_keys.c +10
-0+* transfer the queued keys with the mutex held to a temp list, +* release the mutex, and then process the queued keys from +* the temp list. +* +* Since ima_process_keys is set to true, any new key will be +* processed immediately and not be queued. +*/ +INIT_LIST_HEAD (&temp_ima_keys); + +mutex_lock (&ima_keys_mutex);
Don't you need a test here, before setting ima_process_keys?
if (ima_process_keys) return;
Mimi
Quoted 18 lines
security/integrity/ima/ima_asymmetric_keys.c +17
-0+ + ima_process_keys = true; + +list_for_each_entry_safe (entry, tmp, &ima_keys, list) +list_move_tail (&entry->list, &temp_ima_keys); + +mutex_unlock (&ima_keys_mutex); + +list_for_each_entry_safe (entry, tmp, &temp_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); + } +} +
Re: [PATCH v3 1/2] IMA: Define workqueue for early boot "key" measurements
Quoted 29 lines · Mimi Zohar
Quoted 16 lines
security/integrity/ima/ima_asymmetric_keys.c +16
-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; +LIST_HEAD (temp_ima_keys); + +if (ima_process_keys) +return ; + +/* +* To avoid holding the mutex when processing queued keys, security/integrity/ima/ima_asymmetric_keys.c line 118
Quoted 10 lines
security/integrity/ima/ima_asymmetric_keys.c +10
-0+* transfer the queued keys with the mutex held to a temp list, +* release the mutex, and then process the queued keys from +* the temp list. +* +* Since ima_process_keys is set to true, any new key will be +* processed immediately and not be queued. +*/ +INIT_LIST_HEAD (&temp_ima_keys); + +mutex_lock (&ima_keys_mutex);Don't you need a test here, before setting
ima_process_keys?
Quoted 4 lines
if (ima_process_keys) return;Mimi
That check is done before the comment - at the start of ima_process_queued_keys().
+void ima_process_queued_keys(void)
+{
+ struct ima_key_entry *entry, *tmp;
+ LIST_HEAD(temp_ima_keys);
+
+ if (ima_process_keys)
+ return;
thanks,
-lakshmi
Mimi Zohar
maintainerRe: [PATCH v3 1/2] IMA: Define workqueue for early boot "key" measurements
Quoted 30 lines · Lakshmi Ramasubramanian
Quoted 29 lines · Mimi Zohar
Quoted 16 lines
security/integrity/ima/ima_asymmetric_keys.c +16
-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; +LIST_HEAD (temp_ima_keys); + +if (ima_process_keys) +return ; + +/* +* To avoid holding the mutex when processing queued keys, security/integrity/ima/ima_asymmetric_keys.c line 118
Quoted 10 lines
security/integrity/ima/ima_asymmetric_keys.c +10
-0+* transfer the queued keys with the mutex held to a temp list, +* release the mutex, and then process the queued keys from +* the temp list. +* +* Since ima_process_keys is set to true, any new key will be +* processed immediately and not be queued. +*/ +INIT_LIST_HEAD (&temp_ima_keys); + +mutex_lock (&ima_keys_mutex);Don't you need a test here, before setting
ima_process_keys?
Quoted 7 lines
Quoted 4 lines
if (ima_process_keys) return;Mimi
That check is done before the comment - at the start of
ima_process_queued_keys().
The first test prevents taking the mutex unnecessarily.
Mimi
Quoted 10 lines
security/integrity/ima/ima_asymmetric_keys.c +7
-0+void ima_process_queued_keys (void ) +{ +struct ima_key_entry *entry, *tmp; +LIST_HEAD (temp_ima_keys); + +if (ima_process_keys) +return ;thanks,
-lakshmi
Re: [PATCH v3 1/2] IMA: Define workqueue for early boot "key" measurements
Quoted 6 lines · Mimi Zohar
Quoted 6 lines
Quoted 6 lines
Don't you need a test here, before setting
ima_process_keys?if (ima_process_keys) return;
Quoted 8 lines
Quoted 4 lines
Quoted 1 line
Mimi
That check is done before the comment - at the start of
ima_process_queued_keys().The first test prevents taking the mutex unnecessarily.
Mimi
I am trying to understand your concern here. Could you please clarify?
=> If ima_process_keys is false
-> With the mutex held, should check ima_process_keys again
before setting?
Let's say 2 or more threads are racing in calling ima_process_queued_keys():
The 1st one will set ima_process_keys and process queued keys.
The 2nd and subsequent ones - even if they have gone past the initial check, will find an empty list of keys (the list "ima_keys") when they take the mutex. So they'll not process any keys.
thanks,
-lakshmi
Mimi Zohar
maintainerRe: [PATCH v3 1/2] IMA: Define workqueue for early boot "key" measurements
Quoted 20 lines · Lakshmi Ramasubramanian
Quoted 11 lines · Mimi Zohar
Quoted 8 lines
Quoted 5 lines
Don't you need a test here, before setting
ima_process_keys?if (ima_process_keys) return;That check is done before the comment - at the start of
ima_process_queued_keys().The first test prevents taking the mutex unnecessarily.
I am trying to understand your concern here. Could you please clarify?
=> If
ima_process_keysis false-> With the mutex held, should check ima_process_keys againbefore setting?
Quoted 7 lines
Let's say 2 or more threads are racing in calling
ima_process_queued_keys():The 1st one will set
ima_process_keysand process queued keys.The 2nd and subsequent ones - even if they have gone past the initial check, will find an empty list of keys (the list "
ima_keys") when they take the mutex. So they'll not process any keys.
I just need to convince myself that this is correct. Normally before reading and writing a flag, there is some sort of locking. With taking the mutex before setting the flag, there is now only a lock around the single writer.
Without taking a lock before reading the flag, will the queue always be empty is the question. If it is, then the comment is correct, but the code assumes not and processes the list again. Testing the flag after taking the mutex just re-enforces the comment.
Bottom line, does reading the flag need to be lock protected?
Mimi
Re: [PATCH v3 1/2] IMA: Define workqueue for early boot "key" measurements
Quoted 5 lines · Mimi Zohar
I just need to convince myself that this is correct. Normally before reading and writing a flag, there is some sort of locking. With taking the mutex before setting the flag, there is now only a lock around the single writer.
Quoted 9 lines
Without taking a lock before reading the flag, will the queue always be empty is the question. If it is, then the comment is correct, but the code assumes not and processes the list again. Testing the flag after taking the mutex just re-enforces the comment.
Bottom line, does reading the flag need to be lock protected?
Mimi
I'll change this function to check the flag again after taking the lock and process only if the queue has entries. Will send an update today.
Please let me know if you have any concern in other functions in this file. I'll address them, if any, in today's update.
thanks,
-lakshmi
Mimi Zohar
maintainerRe: [PATCH v3 1/2] IMA: Define workqueue for early boot "key" measurements
In reply to Mimi ZoharQuoted 34 lines · Mimi Zohar
Quoted 20 lines · Lakshmi Ramasubramanian
Quoted 11 lines · Mimi Zohar
Quoted 8 lines
Quoted 5 lines
Don't you need a test here, before setting
ima_process_keys?if (ima_process_keys) return;That check is done before the comment - at the start of
ima_process_queued_keys().The first test prevents taking the mutex unnecessarily.
I am trying to understand your concern here. Could you please clarify?
=> If
ima_process_keysis false-> With the mutex held, should check ima_process_keys againbefore setting?
Quoted 7 lines
Let's say 2 or more threads are racing in calling
ima_process_queued_keys():The 1st one will set
ima_process_keysand process queued keys.The 2nd and subsequent ones - even if they have gone past the initial check, will find an empty list of keys (the list "
ima_keys") when they take the mutex. So they'll not process any keys.I just need to convince myself that this is correct. Normally before reading and writing a flag, there is some sort of locking. With taking the mutex before setting the flag, there is now only a lock around the single writer.
Quoted 6 lines
Without taking a lock before reading the flag, will the queue always be empty is the question. If it is, then the comment is correct, but the code assumes not and processes the list again. Testing the flag after taking the mutex just re-enforces the comment.
Bottom line, does reading the flag need to be lock protected?
Reading the flag IS lock protected, just spread across two functions. For performance, ima_post_key_create_or_update() checks ima_process_keys, before calling ima_queue_key(), which takes the mutex before checking ima_process_keys again.
As long as both the reader and writer, take the mutex before checking the flag, the locking is fine. The additional check, before taking the mutex, is simply for performance.
Mimi
PATCH v3 2/2 IMA: Call workqueue functions to measure queued keys
In reply to Lakshmi RamasubramanianMeasuring 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.
--- 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
@@ -149,6 +149,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 ;
@@ -156,6 +158,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
@@ -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