On Fri, Jun 28, 2019 at 11:47 AM Matthew Garrett <mjg59@xxxxxxxxxx> wrote: > > On Thu, Jun 27, 2019 at 4:27 PM Andy Lutomirski <luto@xxxxxxxxxx> wrote: > > They're really quite similar in my mind. Certainly some things in the > > "integrity" category give absolutely trivial control over the kernel > > (e.g. modules) while others make it quite challenging (ioperm), but > > the end result is very similar. And quite a few "confidentiality" > > things genuinely do allow all kernel memory to be read. > > > > I agree that finer-grained distinctions could be useful. My concern is > > that it's a tradeoff, and the other end of the tradeoff is an ABI > > stability issue. If someone decides down the road that some feature > > that is currently "integrity" can be split into a narrow "integrity" > > feature and a "confidentiality" feature then, if the user policy knows > > about the individual features, there's a risk of breaking people's > > systems. If we keep the fine-grained control, do we have a clear > > compatibility story? > > My preference right now is to retain the fine-grained aspect of things > in the internal API, simply because it'll be more annoying to add it > back later if we want to. I don't want to expose it via the Lockdown > user facing API for the reasons you've described, but it's not > impossible that another LSM would find a way to do this reasonably. > Does it seem reasonable to punt this discussion out to the point where > another LSM tries to do something with this information, based on the > implementation they're attempting? I think I can get behind this, as long as it's clear to LSM authors that this list is only a little bit stable. I can certainly see the use for the fine-grained info being available for auditing.
