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:
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 | 118 +++++++++++++++++++
security/integrity/ima/ima_policy.c | 3 +
3 files changed, 136 insertions(+)
--
2.17.1
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 | 110 +++++++++++++++++++
2 files changed, 125 insertions(+)
diff --git a/security/integrity/ima/ima.h b/security/integrity/ima/ima.h
index f06238e41a7c..97f8a4078483 100644
--- a/security/integrity/ima/ima.h
+++ b/security/integrity/ima/ima.h
@@ -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,
diff --git a/security/integrity/ima/ima_asymmetric_keys.c b/security/integrity/ima/ima_asymmetric_keys.c
index fea2e7dd3b09..ba01e04ec025 100644
--- a/security/integrity/ima/ima_asymmetric_keys.c
+++ b/security/integrity/ima/ima_asymmetric_keys.c
@@ -14,6 +14,116 @@
#include <keys/asymmetric-type.h>
#include "ima.h"
+/*
+ * Flag to indicate whether a key can be processed
+ * right away or should be queued for processing later.
+ */
+bool ima_process_keys;
+
+/*
+ * To synchronize access to the list of keys that need to be measured
+ */
+static DEFINE_MUTEX(ima_keys_mutex);
+static LIST_HEAD(ima_keys);
+
+static void ima_free_key_entry(struct ima_key_entry *entry)
+{
+ if (entry) {
+ kfree(entry->payload);
+ kfree(entry->keyring_name);
+ kfree(entry);
+ }
+}
+
+static struct ima_key_entry *ima_alloc_key_entry(
+ struct key *keyring,
+ const void *payload, size_t payload_len)
+{
+ int rc = 0;
+ struct ima_key_entry *entry;
+
+ entry = kzalloc(sizeof(*entry), GFP_KERNEL);
+ if (entry) {
+ entry->payload = kmemdup(payload, payload_len, GFP_KERNEL);
+ entry->keyring_name = kstrdup(keyring->description,
+ GFP_KERNEL);
+ entry->payload_len = payload_len;
+ }
+
+ if ((entry == NULL) || (entry->payload == NULL) ||
+ (entry->keyring_name == NULL)) {
+ rc = -ENOMEM;
+ goto out;
+ }
+
+ INIT_LIST_HEAD(&entry->list);
+
+out:
+ if (rc) {
+ ima_free_key_entry(entry);
+ entry = NULL;
+ }
+
+ return entry;
+}
+
+bool ima_queue_key(struct key *keyring, const void *payload,
+ size_t payload_len)
+{
+ bool queued = false;
+ struct ima_key_entry *entry;
+
+ entry = ima_alloc_key_entry(keyring, payload, payload_len);
+ if (!entry)
+ return false;
+
+ mutex_lock(&ima_keys_mutex);
+ if (!ima_process_keys) {
+ list_add_tail(&entry->list, &ima_keys);
+ queued = true;
+ }
+ mutex_unlock(&ima_keys_mutex);
+
+ if (!queued)
+ ima_free_key_entry(entry);
+
+ return queued;
+}
+
+/*
+ * 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;
+
+ ima_process_keys = true;
+
+ INIT_LIST_HEAD(&temp_ima_keys);
+
+ mutex_lock(&ima_keys_mutex);
+
+ 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);
+ }
+}
+
/**
* ima_post_key_create_or_update - measure asymmetric keys
* @keyring: keyring to which the key is linked to
--
2.17.1
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.
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(+)
diff --git a/security/integrity/ima/ima_asymmetric_keys.c b/security/integrity/ima/ima_asymmetric_keys.c
index ba01e04ec025..61b801ff3747 100644
--- a/security/integrity/ima/ima_asymmetric_keys.c
+++ b/security/integrity/ima/ima_asymmetric_keys.c
@@ -140,6 +140,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;
@@ -147,6 +149,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
diff --git a/security/integrity/ima/ima_policy.c b/security/integrity/ima/ima_policy.c
index a4dde9d575b2..04b9c6c555de 100644
--- a/security/integrity/ima/ima_policy.c
+++ b/security/integrity/ima/ima_policy.c
@@ -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! */
--
2.17.1
On Wed, 2019-12-11 at 10:51 -0800, Lakshmi Ramasubramanian wrote:
> 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 | 110 +++++++++++++++++++
> 2 files changed, 125 insertions(+)
>
> diff --git a/security/integrity/ima/ima.h b/security/integrity/ima/ima.h
> index f06238e41a7c..97f8a4078483 100644
> --- a/security/integrity/ima/ima.h
> +++ b/security/integrity/ima/ima.h
> @@ -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,
> diff --git a/security/integrity/ima/ima_asymmetric_keys.c b/security/integrity/ima/ima_asymmetric_keys.c
> index fea2e7dd3b09..ba01e04ec025 100644
> --- a/security/integrity/ima/ima_asymmetric_keys.c
> +++ b/security/integrity/ima/ima_asymmetric_keys.c
> @@ -14,6 +14,116 @@
> #include <keys/asymmetric-type.h>
> #include "ima.h"
>
> +/*
> + * Flag to indicate whether a key can be processed
> + * right away or should be queued for processing later.
> + */
> +bool ima_process_keys;
> +
> +/*
> + * To synchronize access to the list of keys that need to be measured
> + */
> +static DEFINE_MUTEX(ima_keys_mutex);
> +static LIST_HEAD(ima_keys);
> +
> +static void ima_free_key_entry(struct ima_key_entry *entry)
> +{
> + if (entry) {
> + kfree(entry->payload);
> + kfree(entry->keyring_name);
> + kfree(entry);
> + }
> +}
> +
> +static struct ima_key_entry *ima_alloc_key_entry(
> + struct key *keyring,
> + const void *payload, size_t payload_len)
> +{
> + int rc = 0;
> + struct ima_key_entry *entry;
> +
> + entry = kzalloc(sizeof(*entry), GFP_KERNEL);
> + if (entry) {
> + entry->payload = kmemdup(payload, payload_len, GFP_KERNEL);
> + entry->keyring_name = kstrdup(keyring->description,
> + GFP_KERNEL);
> + entry->payload_len = payload_len;
> + }
> +
> + if ((entry == NULL) || (entry->payload == NULL) ||
> + (entry->keyring_name == NULL)) {
> + rc = -ENOMEM;
> + goto out;
> + }
> +
> + INIT_LIST_HEAD(&entry->list);
> +
> +out:
> + if (rc) {
> + ima_free_key_entry(entry);
> + entry = NULL;
> + }
> +
> + return entry;
> +}
> +
> +bool ima_queue_key(struct key *keyring, const void *payload,
> + size_t payload_len)
> +{
> + bool queued = false;
> + struct ima_key_entry *entry;
> +
> + entry = ima_alloc_key_entry(keyring, payload, payload_len);
> + if (!entry)
> + return false;
> +
> + mutex_lock(&ima_keys_mutex);
> + if (!ima_process_keys) {
> + list_add_tail(&entry->list, &ima_keys);
> + queued = true;
> + }
> + mutex_unlock(&ima_keys_mutex);
> +
> + if (!queued)
> + ima_free_key_entry(entry);
> +
> + return queued;
> +}
> +
> +/*
> + * 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;
> +
> + ima_process_keys = true;
> +
> + INIT_LIST_HEAD(&temp_ima_keys);
> +
> + mutex_lock(&ima_keys_mutex);
> +
> + list_for_each_entry_safe(entry, tmp, &ima_keys, list)
> + list_move_tail(&entry->list, &temp_ima_keys);
> +
> + mutex_unlock(&ima_keys_mutex);
The v1 comment, which explained the need for using a temporary
keyring, is an example of an informative comment. If you don't
object, instead of re-posting this patch, I can insert it.
Mimi
> +
> + 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);
> + }
> +}
> +
> /**
> * ima_post_key_create_or_update - measure asymmetric keys
> * @keyring: keyring to which the key is linked to
On 12/12/19 12:19 AM, Mimi Zohar wrote:
>>> + ima_process_keys = true;
>> +
>> + INIT_LIST_HEAD(&temp_ima_keys);
>> +
>> + mutex_lock(&ima_keys_mutex);
>> +
>> + list_for_each_entry_safe(entry, tmp, &ima_keys, list)
>> + list_move_tail(&entry->list, &temp_ima_keys);
>> +
>> + mutex_unlock(&ima_keys_mutex);
>
>
> The v1 comment, which explained the need for using a temporary
> keyring, is an example of an informative comment. If you don't
> object, instead of re-posting this patch, I can insert it.
>
> Mimi
Sure Mimi. Thanks for including the comment in the patch.
thanks,
-lakshmi
On Thu, 2019-12-12 at 08:57 -0800, Lakshmi Ramasubramanian wrote:
> On 12/12/19 12:19 AM, Mimi Zohar wrote:
>
> >>> + ima_process_keys = true;
> >> +
> >> + INIT_LIST_HEAD(&temp_ima_keys);
> >> +
> >> + mutex_lock(&ima_keys_mutex);
> >> +
> >> + list_for_each_entry_safe(entry, tmp, &ima_keys, list)
> >> + list_move_tail(&entry->list, &temp_ima_keys);
> >> +
> >> + mutex_unlock(&ima_keys_mutex);
> >
> >
> > The v1 comment, which explained the need for using a temporary
> > keyring, is an example of an informative comment. If you don't
> > object, instead of re-posting this patch, I can insert it.
>
> Sure Mimi. Thanks for including the comment in the patch.
Looking at this again, something seems off or at least the comment
doesn't match the code.
/*
* To avoid holding the mutex while processing queued keys,
* 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 above, any new key will
* be processed immediately and not queued.
*/
Setting ima_process_key before taking the lock won't prevent the race.
I think you want to test ima_process_keys before taking the lock and
again immediately afterward taking the lock, before setting it. Then
the comment would match the code.
Shouldn't ima_process_keys be defined as static to limit the scope to
this file?
Mimi
On 12/12/19 1:13 PM, Mimi Zohar wrote:
>
> Looking at this again, something seems off or at least the comment
> doesn't match the code.
>
> /*
> * To avoid holding the mutex while processing queued keys,
> * 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 above, any new key will
> * be processed immediately and not queued.
> */
>
> Setting ima_process_key before taking the lock won't prevent the race.
> I think you want to test ima_process_keys before taking the lock and
> again immediately afterward taking the lock, before setting it. Then
> the comment would match the code.
>
> Shouldn't ima_process_keys be defined as static to limit the scope to
> this file?
>
> Mimi
>
In IMA hook, ima_process_key is checked without lock. If it is false,
ima_queue_key is called. If the key was queued (by ima_queue_key()) then
the hook defers measurement. Else, it processes it immediately.
In ima_queue_key() function the check for ima_process_key is done after
taking the lock and the key queued if the flag is false.
In ima_process_keys() ima_process_key is set without lock and then the
queued keys are moved to a temp list after taking the lock.
I have reviewed the changes myself and also with a few of my colleagues.
I don't think there is a race condition. Please let me know if you do
see a problem.
I can move the setting of ima_process_key flag inside the lock. But
honestly I don't think that is necessary.
I agree that ima_process_keys should be static since it is used in this
file one. I'll make that change.
I can also move the setting of ima_process_key flag inside the lock
along with the above change.
thanks,
-lakshmi
On 12/12/2019 2:54 PM, Mimi Zohar wrote:
>>
>> I can also move the setting of ima_process_key flag inside the lock
>> along with the above change.
>
> My concern is with the last sentence "Since ima_process_keys is set to
> true above, any new key will be processed immediately and not queued."
> It's unlikely, but possible, that a second process will wait for the
> ima_keys_mutex. Either we remove this sentence or move setting
> ima_process_keys to after taking the lock.
>
> Mimi
Sure - i'll move the setting of ima_process_keys flag inside the lock
and define the flag as static. Will keep the comment as is.
thanks,
-lakshmi
On Thu, 2019-12-12 at 13:59 -0800, Lakshmi Ramasubramanian wrote:
> On 12/12/19 1:13 PM, Mimi Zohar wrote:
>
> >
> > Looking at this again, something seems off or at least the comment
> > doesn't match the code.
> >
> > /*
> > * To avoid holding the mutex while processing queued keys,
> > * 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 above, any new key will
> > * be processed immediately and not queued.
> > */
> >
> > Setting ima_process_key before taking the lock won't prevent the race.
> > I think you want to test ima_process_keys before taking the lock and
> > again immediately afterward taking the lock, before setting it. Then
> > the comment would match the code.
> >
> > Shouldn't ima_process_keys be defined as static to limit the scope to
> > this file?
> >
> > Mimi
> >
>
> In IMA hook, ima_process_key is checked without lock. If it is false,
> ima_queue_key is called. If the key was queued (by ima_queue_key()) then
> the hook defers measurement. Else, it processes it immediately.
>
> In ima_queue_key() function the check for ima_process_key is done after
> taking the lock and the key queued if the flag is false.
>
> In ima_process_keys() ima_process_key is set without lock and then the
> queued keys are moved to a temp list after taking the lock.
>
> I have reviewed the changes myself and also with a few of my colleagues.
> I don't think there is a race condition. Please let me know if you do
> see a problem.
>
> I can move the setting of ima_process_key flag inside the lock. But
> honestly I don't think that is necessary.
>
> I agree that ima_process_keys should be static since it is used in this
> file one. I'll make that change.
>
> I can also move the setting of ima_process_key flag inside the lock
> along with the above change.
My concern is with the last sentence "Since ima_process_keys is set to
true above, any new key will be processed immediately and not queued."
It's unlikely, but possible, that a second process will wait for the
ima_keys_mutex. Either we remove this sentence or move setting
ima_process_keys to after taking the lock.
Mimi