On Fri, Feb 28, 2025 at 12:19 PM Mimi Zohar <zohar@xxxxxxxxxxxxx> wrote: > 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: ... > 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. Perhaps we're not understanding each other, but my understanding of the above three scenarios is that they are all examples of signed applications where something (likely something in the kernel like IMA) verifies the signature on the application. While there are going to be differing numbers of keys in each of the three scenarios, I believe they would all be on/linked-to the same usage oriented keyring as they all share the same usage: application signatures. > > 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. Unfortunately I think we're getting a little ambiguous with how we are using the word "trust". Just as "security" can mean different things depending on context, so can "trust" as the qualities we are trusting will vary depending on context. I'll leave it at that for now as I believe we are talking about different things in the paragraphs above. Regardless, I'll also say this regarding Clavis and key/keyring access controls - as implemented, Clavis doesn't look like a LSM to me for the reasons already given. If all of the various keys subsystem maintainers believe it is the Right Thing To Do inside the keys subsystem then it isn't my place to have a say in that. I personally believe that doing the work to support usage oriented keyrings before, or while, implementing a Clavis-like mechanism is the better option, but that is a decision for you and the other key maintainers. -- paul-moore.com
