On Mon, 2025-03-03 at 17:38 -0500, Paul Moore wrote: > 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. Yes they're all verifying file signatures, but the software packages are from different sources (e.g. distro, chrome), signed by different keys. Only a particular key should be used to verify the file signatures for a particular application. The scenarios, described above, are the ratio of distro/single entity vs. non distro/single entity signed packages, which would correspond to the number of keyrings. Clavis limits key usage based on LSM hooks (e.g. kernel modules, kernel image, firmware, etc). It's a good start, but even this probably is not fine enough granularity. > > > > 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. "Usage oriented keyrings" similarly implies any key on a particular keyring is acceptable. Without understanding what you mean by "usage oriented keyrings", I would assume it would work initially, but eventually it too will not be fine enough granularity. Mimi
