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?
