[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <0c81515a-0f0c-cec4-941f-3de4a8bc8a2c@linux.microsoft.com>
Date: Mon, 28 Oct 2019 08:56:52 -0700
From: Lakshmi Ramasubramanian <nramas@...ux.microsoft.com>
To: Mimi Zohar <zohar@...ux.ibm.com>, dhowells@...hat.com,
casey@...aufler-ca.com, sashal@...nel.org,
jamorris@...ux.microsoft.com,
linux-security-module@...r.kernel.org,
linux-integrity@...r.kernel.org, linux-kernel@...r.kernel.org,
keyrings@...r.kernel.org
Subject: Re: [PATCH v2 3/4] KEYS: Added BUILTIN_TRUSTED_KEYS enum to measure
keys added to builtin_trusted_keys keyring
On 10/27/19 7:33 AM, Mimi Zohar wrote:
> Other examples of trusted keyrings are: .ima, .evm, .platform,
> .blacklist, .builtin_regdb_keys. Instead of defining a keyring
> specific method of getting the keyring number, define a generic
> method. For example, the userspace command "keyctl describe
> %keyring:.builtin_trusted_keys" searches /proc/keys, but the kernel
> shouldn't need to access /proc/keys.
"description" field in "struct key" is set to ".builtin_trusted_keys"
for Built-In Trusted Keys keyring.
Similarly, for other keyrings such as .ima, .evm, .blacklist,
.builtin_regdb_keys, etc.
> # measure keys on the BUILTIN and IMA keyrings into a different PCR
> measure func=KEYRING_CHECK keyring=".builtin_trusted_keys|.ima" pcr=11
With IMA policy set like above, the keyring to keyring number mapping
can be set at IMA policy load.
My earlier point about mapping the "keyring" to "keyring number" at
runtime (when the IMA hook is called) still needs to be done to know if
the given keyring is in the policy or not.
void ima_post_key_create_or_update(struct key *keyring, struct key *key,
unsigned long flags, bool create)
thanks,
-lakshmi
Powered by blists - more mailing lists