linux-integrity.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Lakshmi Ramasubramanian <nramas@linux.microsoft.com>
To: Mimi Zohar <zohar@linux.ibm.com>, linux-integrity@vger.kernel.org
Cc: eric.snowberg@oracle.com, dhowells@redhat.com,
	matthewgarrett@google.com, sashal@kernel.org,
	jamorris@linux.microsoft.com, linux-kernel@vger.kernel.org,
	keyrings@vger.kernel.org
Subject: Re: [PATCH v0 2/2] IMA: Call queue functions to measure keys
Date: Tue, 3 Dec 2019 08:09:20 -0800	[thread overview]
Message-ID: <e89dcb1c-c463-919a-aabb-e285d884a914@linux.microsoft.com> (raw)
In-Reply-To: <1575331353.4793.471.camel@linux.ibm.com>

Thanks for reviewing the changes Mimi. I'll address your comments in the 
next update.

> 
> Overwriting the initial policy is highly recommended, but not everyone
> defines a custom policy.  Should there be a time limit or some other
> criteria before deleting the key measurement queue?
> 
> Mimi

For the above, I feel checking for the presence of custom policy, if 
that is possible, would be a more deterministic approach compared to 
having a time limit.

On my machine, systemd loads the custom IMA policy from 
/etc/ima/ima-policy if that file is present. Is this the recommended way 
to configure custom IMA policy? If yes, can the IMA initialization 
function check for the presence of the above file?

Another way to address this issue is to define a new CONFIG parameter to 
determine whether or not to support deferred processing of keys. If this 
config is chosen, custom IMA policy must be defined.

Least preferred option would be to leave the queued keys as is if custom 
policy is not defined - at the cost of, maybe, a non-trivial amount of 
kernel memory consumed.

If detection of custom policy is not possible, then define a timer to 
drain the key measurement queue.

Please let me know which approach you think is optimal.

thanks,
  -lakshmi


      reply	other threads:[~2019-12-03 16:09 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-27  2:52 [PATCH v0 0/2] IMA: Deferred measurement of keys Lakshmi Ramasubramanian
2019-11-27  2:52 ` [PATCH v0 1/2] IMA: Defined queue functions Lakshmi Ramasubramanian
2019-11-27 20:38   ` Mimi Zohar
2019-11-27 21:11     ` Lakshmi Ramasubramanian
2019-12-02 18:00       ` Mimi Zohar
2019-12-02 18:39         ` Lakshmi Ramasubramanian
2019-12-02 19:11           ` Mimi Zohar
2019-12-02 20:24             ` Lakshmi Ramasubramanian
2019-12-03  0:02   ` Mimi Zohar
2019-11-27  2:52 ` [PATCH v0 2/2] IMA: Call queue functions to measure keys Lakshmi Ramasubramanian
2019-12-03  0:02   ` Mimi Zohar
2019-12-03 16:09     ` Lakshmi Ramasubramanian [this message]

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=e89dcb1c-c463-919a-aabb-e285d884a914@linux.microsoft.com \
    --to=nramas@linux.microsoft.com \
    --cc=dhowells@redhat.com \
    --cc=eric.snowberg@oracle.com \
    --cc=jamorris@linux.microsoft.com \
    --cc=keyrings@vger.kernel.org \
    --cc=linux-integrity@vger.kernel.org \
    --cc=linux-kernel@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: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).