On Fri, 2025-02-28 at 11:14 -0500, Paul Moore wrote: > On Fri, Feb 28, 2025 at 9:09 AM Mimi Zohar <zohar@xxxxxxxxxxxxx> wrote: > > On Thu, 2025-02-27 at 17:22 -0500, Paul Moore wrote: > > > > > > I'd still also like to see some discussion about moving towards the > > > addition of keyrings oriented towards usage instead of limiting > > > ourselves to keyrings that are oriented on the source of the keys. > > > Perhaps I'm missing some important detail which makes this > > > impractical, but it seems like an obvious improvement to me and would > > > go a long way towards solving some of the problems that we typically > > > see with kernel keys. > > > > The proliferation of keyrings won't solve the key usage problem for IMA- > > appraisal. IMA-appraisal can be used to verify the kexec image, kernel modules, > > firwmare, etc, but it also verifies file signatures contained in userspace > > packages. > > To be clear I don't think the usage oriented keyring idea will solve > every keyring problem, but it seems like it solves a fair number of > things that I've heard lately. > > > To support the latter case, keyrings would need to be application > > specific. (This version of Clavis doesn't solve the latter key usage for IMA- > > appraisal either.) > > Application specific keyrings are more-or-less what I've been trying > to describe. Ok, let's go through different scenarios to see if it would scale. Scenario 1: Mostly distro signed userspace applications, minimum number of developer, customer, 3rd party applications. Scenario 2: Multiple developer, customer, 3rd party applications, signed by the same party. Scenario 3: extreme case - every application signed by different party. With the minimum case, there would probably be a default key or sets of permissible keys. In the extreme case, the number of keyrings would be equivalent to the number of application/software packages. > > > The keys baked into the kernel are trusted because the kernel itself was signed > > and verified (secure boot). Anyone building a kernel can build a key into the > > kernel image, which establishes a "root of trust". That key can then be used to > > verify and load other keys onto the IMA keyring. > > Sure, I'm not saying that trust isn't important, and that there are > varying levels of trust. My argument is that having additional, > usage/application oriented keyrings which contain links back to keys > imported and stored in the traditional trust oriented keyrings could > neatly solve a number of keyring access control issues. > > > The problem is how to safely establish a root of trust without baking the key > > into the kernel image and then limiting that trust to specific usages or > > applications. > > My takeaway from Clavis was that it was more about establishing a set > of access controls around keys already present in the keyrings and my > comments about usage/spplication oriented keyrings have been in that > context. While the access control policy, regardless of how it is > implemented, should no doubt incorporate the trust placed in the > individual keys, how that trust is established is a separate issue > from access control as far as I'm concerned. Clavis defined both a mechanism for establishing trust and access control rules. Clavis defined a single Clavis key to establish trust. The Clavis policy rules were signed by the Clavis key. The Clavis policy rules defined the access control. Mimi
