From: Lakshmi Ramasubramanian <nramas@linux.microsoft.com> To: Mimi Zohar <zohar@linux.ibm.com>, dhowells@redhat.com, matthewgarrett@google.com, sashal@kernel.org, jamorris@linux.microsoft.com, linux-integrity@vger.kernel.org, linux-security-module@vger.kernel.org, keyrings@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v4 01/10] IMA: Defined an IMA hook to measure keys on key create or update Date: Thu, 07 Nov 2019 18:42:55 +0000 [thread overview] Message-ID: <7ce84aa0-729e-c58e-f16a-25490b4e336d@linux.microsoft.com> (raw) In-Reply-To: <1573098037.5028.325.camel@linux.ibm.com> On 11/6/2019 7:40 PM, Mimi Zohar wrote: >>> I would move the patch that defines the "keyring=" policy option prior >>> to this one. Include the call to process_buffer_measurement() in this >>> patch. A subsequent patch would add support to defer measuring the >>> key, by calling a function named something like >>> ima_queue_key_measurement(). >>> >>> Mimi >> >> As I'd stated in the other response, I wanted to isolate all key related >> code in a separate C file and build it if and only if all CONFIG >> dependencies are met. > > The basic measuring of keys shouldn't be any different than any other > policy rule, other than it is a key and not a file. This is the > reason that I keep saying start out with the basics and then add > support to defer measuring keys on the trusted keyrings. I'll make the changes, rearrange the patches and send an updated set. I do have a few questions since I am still not fully understanding the requirements you are targeting. Appreciate if you could please clarify. As you already know, I am using the "public key" of the given asymmetric key as the "buffer" to measure in process_buffer_measurement(). The measurement decision is not based on whether the keyring is a trusted one or an untrusted one. As long as the IMA policy allows (through the "keyrings=" option) the key will be measured. Do you want only trusted keyrings to be allowed in the measurement? In my opinion, that decision should be deferred to whoever is setting up the IMA policy. > Only the queueing code needed for measuring keys on the trusted > keyrings would be in a separate file. > > Mimi The decision to process key immediately or defer (queue) is based on whether IMA has been initialized or not. Keyring is not used for this decision. Could you please clarify how queuing is related to keyring's trustworthiness? The check for whether the key is an asymmetric one or not, and extracting the "public key" if it is an asymmetric key needs to be in a separate file to handle the CONFIG dependencies in IMA. thanks, -lakshmi
WARNING: multiple messages have this Message-ID (diff)
From: Lakshmi Ramasubramanian <nramas@linux.microsoft.com> To: Mimi Zohar <zohar@linux.ibm.com>, dhowells@redhat.com, matthewgarrett@google.com, sashal@kernel.org, jamorris@linux.microsoft.com, linux-integrity@vger.kernel.org, linux-security-module@vger.kernel.org, keyrings@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v4 01/10] IMA: Defined an IMA hook to measure keys on key create or update Date: Thu, 7 Nov 2019 10:42:55 -0800 [thread overview] Message-ID: <7ce84aa0-729e-c58e-f16a-25490b4e336d@linux.microsoft.com> (raw) In-Reply-To: <1573098037.5028.325.camel@linux.ibm.com> On 11/6/2019 7:40 PM, Mimi Zohar wrote: >>> I would move the patch that defines the "keyring=" policy option prior >>> to this one. Include the call to process_buffer_measurement() in this >>> patch. A subsequent patch would add support to defer measuring the >>> key, by calling a function named something like >>> ima_queue_key_measurement(). >>> >>> Mimi >> >> As I'd stated in the other response, I wanted to isolate all key related >> code in a separate C file and build it if and only if all CONFIG >> dependencies are met. > > The basic measuring of keys shouldn't be any different than any other > policy rule, other than it is a key and not a file. This is the > reason that I keep saying start out with the basics and then add > support to defer measuring keys on the trusted keyrings. I'll make the changes, rearrange the patches and send an updated set. I do have a few questions since I am still not fully understanding the requirements you are targeting. Appreciate if you could please clarify. As you already know, I am using the "public key" of the given asymmetric key as the "buffer" to measure in process_buffer_measurement(). The measurement decision is not based on whether the keyring is a trusted one or an untrusted one. As long as the IMA policy allows (through the "keyrings=" option) the key will be measured. Do you want only trusted keyrings to be allowed in the measurement? In my opinion, that decision should be deferred to whoever is setting up the IMA policy. > Only the queueing code needed for measuring keys on the trusted > keyrings would be in a separate file. > > Mimi The decision to process key immediately or defer (queue) is based on whether IMA has been initialized or not. Keyring is not used for this decision. Could you please clarify how queuing is related to keyring's trustworthiness? The check for whether the key is an asymmetric one or not, and extracting the "public key" if it is an asymmetric key needs to be in a separate file to handle the CONFIG dependencies in IMA. thanks, -lakshmi
next prev parent reply other threads:[~2019-11-07 18:42 UTC|newest] Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-11-06 19:01 [PATCH v4 0/10] KEYS: Measure keys when they are created or updated Lakshmi Ramasubramanian 2019-11-06 19:01 ` Lakshmi Ramasubramanian 2019-11-06 19:01 ` [PATCH v4 01/10] IMA: Defined an IMA hook to measure keys on key create or update Lakshmi Ramasubramanian 2019-11-06 19:01 ` Lakshmi Ramasubramanian 2019-11-06 22:43 ` Mimi Zohar 2019-11-06 22:43 ` Mimi Zohar 2019-11-07 0:21 ` Lakshmi Ramasubramanian 2019-11-07 0:21 ` Lakshmi Ramasubramanian 2019-11-07 3:40 ` Mimi Zohar 2019-11-07 3:40 ` Mimi Zohar 2019-11-07 18:42 ` Lakshmi Ramasubramanian [this message] 2019-11-07 18:42 ` Lakshmi Ramasubramanian 2019-11-07 20:53 ` Mimi Zohar 2019-11-07 20:53 ` Mimi Zohar 2019-11-07 21:12 ` Lakshmi Ramasubramanian 2019-11-07 21:12 ` Lakshmi Ramasubramanian 2019-11-06 19:01 ` [PATCH v4 02/10] IMA: Added KEYRING_CHECK func in IMA policy to measure keys Lakshmi Ramasubramanian 2019-11-06 19:01 ` Lakshmi Ramasubramanian 2019-11-06 19:01 ` [PATCH v4 03/10] IMA: Added keyrings= option in IMA policy to only measure keys added to the specifi Lakshmi Ramasubramanian 2019-11-06 19:01 ` [PATCH v4 03/10] IMA: Added keyrings= option in IMA policy to only measure keys added to the specified keyrings Lakshmi Ramasubramanian 2019-11-06 19:01 ` [PATCH v4 04/10] IMA: Read keyrings= option from the IMA policy into ima_rule_entry Lakshmi Ramasubramanian 2019-11-06 19:01 ` Lakshmi Ramasubramanian 2019-11-06 19:01 ` [PATCH v4 05/10] IMA: Updated IMA policy functions to return keyrings option read from the policy Lakshmi Ramasubramanian 2019-11-06 19:01 ` Lakshmi Ramasubramanian 2019-11-06 19:01 ` [PATCH v4 06/10] IMA: Measure key if the IMA policy allows measurement for the keyring to which the Lakshmi Ramasubramanian 2019-11-06 19:01 ` [PATCH v4 06/10] IMA: Measure key if the IMA policy allows measurement for the keyring to which the key is linked to Lakshmi Ramasubramanian 2019-11-06 19:01 ` [PATCH v4 07/10] IMA: Added a boolean flag to track IMA initialization status Lakshmi Ramasubramanian 2019-11-06 19:01 ` Lakshmi Ramasubramanian 2019-11-06 19:01 ` [PATCH v4 08/10] IMA: Defined functions to queue and dequeue keys for measurement Lakshmi Ramasubramanian 2019-11-06 19:01 ` Lakshmi Ramasubramanian 2019-11-06 22:44 ` Mimi Zohar 2019-11-06 22:44 ` Mimi Zohar 2019-11-06 23:52 ` Lakshmi Ramasubramanian 2019-11-06 23:52 ` Lakshmi Ramasubramanian 2019-11-07 2:20 ` Lakshmi Ramasubramanian 2019-11-07 2:20 ` Lakshmi Ramasubramanian 2019-11-06 19:01 ` [PATCH v4 09/10] IMA: Call queue and dequeue functions to measure keys Lakshmi Ramasubramanian 2019-11-06 19:01 ` Lakshmi Ramasubramanian 2019-11-06 19:01 ` [PATCH v4 10/10] KEYS: Call the IMA hook to measure key when a new key is created or an existing key Lakshmi Ramasubramanian 2019-11-06 19:01 ` [PATCH v4 10/10] KEYS: Call the IMA hook to measure key when a new key is created or an existing key is updated Lakshmi Ramasubramanian
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=7ce84aa0-729e-c58e-f16a-25490b4e336d@linux.microsoft.com \ --to=nramas@linux.microsoft.com \ --cc=dhowells@redhat.com \ --cc=jamorris@linux.microsoft.com \ --cc=keyrings@vger.kernel.org \ --cc=linux-integrity@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-security-module@vger.kernel.org \ --cc=matthewgarrett@google.com \ --cc=sashal@kernel.org \ --cc=zohar@linux.ibm.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.