Re: [PATCH v9 5/6] IMA: Add support to limit measuring keys

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Linux Kernel]     [Linux Kernel Hardening]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux SCSI]

  Powered by Linux