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:
v4
=> Check and set ima_process_keys flag with mutex held.
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 | 136 +++++++++++++++++++
security/integrity/ima/ima_policy.c | 3 +
3 files changed, 154 insertions(+)
--
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.
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:
cat /sys/kernel/security/integrity/ima/ascii_runtime_measurements | grep -m 1 "\.builtin_trusted_keys" | cut -d' ' -f 6 | xxd -r -p |tee btk-cert.der | sha256sum | cut -d' ' -f 1
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(+)
diff --git a/security/integrity/ima/ima_asymmetric_keys.c b/security/integrity/ima/ima_asymmetric_keys.c
index ae6de1bb2e79..8a9d8bc7e10d 100644
--- a/security/integrity/ima/ima_asymmetric_keys.c
+++ b/security/integrity/ima/ima_asymmetric_keys.c
@@ -158,6 +158,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;
@@ -165,6 +167,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
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 | 128 +++++++++++++++++++
2 files changed, 143 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..ae6de1bb2e79 100644
--- a/security/integrity/ima/ima_asymmetric_keys.c
+++ b/security/integrity/ima/ima_asymmetric_keys.c
@@ -14,6 +14,134 @@
#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.
+ */
+static 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);
+ bool process = false;
+
+ if (ima_process_keys)
+ return;
+
+ /*
+ * To avoid holding the mutex when 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, any new key will be
+ * processed immediately and not be queued.
+ */
+ INIT_LIST_HEAD(&temp_ima_keys);
+
+ mutex_lock(&ima_keys_mutex);
+
+ if (!ima_process_keys) {
+ ima_process_keys = true;
+
+ if (!list_empty(&ima_keys)) {
+ list_for_each_entry_safe(entry, tmp, &ima_keys, list)
+ list_move_tail(&entry->list, &temp_ima_keys);
+ process = true;
+ }
+ }
+
+ mutex_unlock(&ima_keys_mutex);
+
+ if (!process)
+ return;
+
+ 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
On Fri, 2019-12-13 at 09:18 -0800, Lakshmi Ramasubramanian wrote:
[...]
> @@ -165,6 +167,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();
> }
There's no locking around the ima_process_keys flag. If you get two
policy updates in quick succession can't this flag change as you're
processing the second update meaning you lose it because the flag was
false when you decided to build it for the queue but becomes true
before you check above whether you need to queue it?
Note you don't need locking to fix this, you just need to ensure that
you use the same copy of the flag value for both tests.
James
On 12/13/19 9:25 AM, James Bottomley wrote:
Hi James,
>
> There's no locking around the ima_process_keys flag. If you get two
> policy updates in quick succession can't this flag change as you're
> processing the second update meaning you lose it because the flag was
> false when you decided to build it for the queue but becomes true
> before you check above whether you need to queue it?
>
> Note you don't need locking to fix this, you just need to ensure that
> you use the same copy of the flag value for both tests.
>
> James
>
Same flag (ima_process_keys) is used for making the queuing decision.
Taking a lock to access ima_process_keys is required only if the flag is
false. That is handled in ima_queue_key() and ima_process_queued_keys()
functions.
Queued keys are processed when the first policy update occurs.
Subsequently, the keys are processed immediately (not queued).
Could you please review those functions in this patch and let me know if
you see a problem?
thanks,
-lakshmi
On Fri, 2019-12-13 at 09:31 -0800, Lakshmi Ramasubramanian wrote:
> On 12/13/19 9:25 AM, James Bottomley wrote:
>
> Hi James,
>
> >
> > There's no locking around the ima_process_keys flag. If you get
> > two policy updates in quick succession can't this flag change as
> > you're processing the second update meaning you lose it because the
> > flag was false when you decided to build it for the queue but
> > becomes true before you check above whether you need to queue it?
> >
> > Note you don't need locking to fix this, you just need to ensure
> > that you use the same copy of the flag value for both tests.
> >
> > James
> >
>
> Same flag (ima_process_keys) is used for making the queuing decision.
>
> Taking a lock to access ima_process_keys is required only if the flag
> is false. That is handled in ima_queue_key() and
> ima_process_queued_keys() functions.
>
> Queued keys are processed when the first policy update occurs.
> Subsequently, the keys are processed immediately (not queued).
>
> Could you please review those functions in this patch and let me know
> if you see a problem?
This is the problem:
if (!flag)
pre()
.
.
.
if (!flag)
post()
And your pre and post function either have to both run or neither must.
However, the flag is set asynchronously, so if it gets set while
another thread is running through the above code, it can change after
pre is run but before post is.
James
On 12/15/2019 7:22 AM, James Bottomley wrote:
Hi James,
>
> This is the problem:
>
> if (!flag)
> pre()
> .
> .
> .
> if (!flag)
> post()
>
> And your pre and post function either have to both run or neither must.
> However, the flag is set asynchronously, so if it gets set while
> another thread is running through the above code, it can change after
> pre is run but before post is.
>
> James
The pre() and post() functions you have referenced above including the
check for the flag are executed with the mutex held.
Please see Mimi's response to the v3 email. I have copied it below:
************************************
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.
************************************
The flag is checked with the mutex held in the "reader" -
ima_queue_key(). The key is queued with the mutex held only if the flag
is false.
The flag is protected in the "writer" also - ima_process_queued_keys().
The flag is checked with the mutex held, set to true, and queued keys
(if any) are transferred to the temp list.
As Mimi has pointed out the additional check of the flag, before taking
the mutex in ima_post_key_create_or_update() and in
ima_process_queued_keys(), is for performance reason.
If the flag is true, there is no need to take the mutex to check it
again in those functions.
thanks,
-lakshmi