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
next prev parent 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).