linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mimi Zohar <zohar@linux.ibm.com>
To: Lakshmi Ramasubramanian <nramas@linux.microsoft.com>,
	linux-integrity@vger.kernel.org
Cc: Mat Martineau <mathew.j.martineau@linux.intel.com>,
	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,
	Mat Martineau <mathew.j.martineau@linux.intel.com>
Subject: Re: [PATCH v9 5/6] IMA: Add support to limit measuring keys
Date: Wed, 04 Dec 2019 06:16:32 -0500	[thread overview]
Message-ID: <1575458192.5241.99.camel@linux.ibm.com> (raw)
In-Reply-To: <89bb3226-3a2e-c7fa-fff9-3a422739481c@linux.microsoft.com>

[Cc'ing Mat Martineau]

On Tue, 2019-12-03 at 15:37 -0800, Lakshmi Ramasubramanian wrote:
> On 12/3/2019 12:06 PM, Mimi Zohar wrote:
> 
> > Suppose both root and uid 1000 define a keyring named "foo".  The
> > current "keyrings=foo" will measure all keys added to either keyring
> > named "foo".  There needs to be a way to limit measuring keys to a
> > particular keyring named "foo".
> > 
> > Mimi
> 
> Thanks for clarifying.
> 
> Suppose two different non-root users create keyring with the same name 
> "foo" and, say, both are measured, how would we know which keyring 
> measurement belongs to which user?
> 
> Wouldn't it be sufficient to include only keyrings created by "root" 
> (UID value 0) in the key measurement? This will include all the builtin 
> trusted keyrings (such as .builtin_trusted_keys, 
> .secondary_trusted_keys, .ima, .evm, etc.).
> 
> What would be the use case for including keyrings created by non-root 
> users in key measurement?
> 
> Also, since the UID for non-root users can be any integer value (greater 
> than 0), can an an administrator craft a generic IMA policy that would 
> be applicable to all clients in an enterprise?

The integrity subsystem, and other concepts upstreamed to support it,
are being used by different people/companies in different ways.  I
know some of the ways, but not all, as how it is being used.  For
example, Mat Martineau gave an LSS2019-NA talk titled "Using and
Implementing Keyring Restrictions for Userspace".  I don't know if he
would be interested in measuring keys on these restricted userspace
keyrings, but before we limit how a new feature works, we should at
least look to see if that limitation is really necessary.

Mimi


  reply	other threads:[~2019-12-04 11:16 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-27  1:56 [PATCH v9 0/6] KEYS: Measure keys when they are created or updated Lakshmi Ramasubramanian
2019-11-27  1:56 ` [PATCH v9 1/6] IMA: Check IMA policy flag Lakshmi Ramasubramanian
2019-11-27  1:56 ` [PATCH v9 2/6] IMA: Add KEY_CHECK func to measure keys Lakshmi Ramasubramanian
2019-11-27  1:56 ` [PATCH v9 3/6] IMA: Define an IMA hook " Lakshmi Ramasubramanian
2019-11-27  1:56 ` [PATCH v9 4/6] KEYS: Call the " Lakshmi Ramasubramanian
2019-11-27  1:56 ` [PATCH v9 5/6] IMA: Add support to limit measuring keys Lakshmi Ramasubramanian
2019-11-27 18:52   ` Mimi Zohar
2019-11-28  0:44     ` Lakshmi Ramasubramanian
2019-12-02 18:18       ` Mimi Zohar
2019-12-03 12:25   ` Mimi Zohar
2019-12-03 16:13     ` Lakshmi Ramasubramanian
2019-12-03 16:47       ` Mimi Zohar
2019-12-03 19:45     ` Lakshmi Ramasubramanian
2019-12-03 20:06       ` Mimi Zohar
2019-12-03 23:37         ` Lakshmi Ramasubramanian
2019-12-04 11:16           ` Mimi Zohar [this message]
2019-12-04 22:43             ` Lakshmi Ramasubramanian
2019-12-04 23:25             ` Mat Martineau
2019-11-27  1:56 ` [PATCH v9 6/6] IMA: Read keyrings= option from the IMA policy Lakshmi Ramasubramanian
2019-11-27 19:32   ` Mimi Zohar
2019-11-27 22:05     ` 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=1575458192.5241.99.camel@linux.ibm.com \
    --to=zohar@linux.ibm.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=mathew.j.martineau@linux.intel.com \
    --cc=matthewgarrett@google.com \
    --cc=nramas@linux.microsoft.com \
    --cc=sashal@kernel.org \
    /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).