On Wed, 4 Dec 2019, Mimi Zohar wrote:
[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.
The use cases I'm most familiar with could have a use for key measurement
for something like enterprise Wi-Fi root certificates. I'm not sure of the
best way to uniquely identify a key to measure in that scenario, it could
be anchored in various ways (process, session, thread, or user keyrings,
for example) and may be owned by a non-root user. As Lakshmi noted above,
key names are not unique, and I'll add that namespace considerations may
come in to play too.
Keys (including keyrings like .builtin_trusted_keys, .ima, etc) can be
linked to multiple keyrings, maybe you could create a system-level
.ima_measured keyring. You could measure keys that are accessible from
that keyring, and opt in more keys for measurement by linking them to
.ima_measured or a keyring nested within .ima_measured.
--
Mat Martineau
Intel
