On Tue, Nov 9, 2021 at 1:16 PM Daniel Burgener <dburgener@xxxxxxxxxxxxxxxxxxx> wrote: > > On 11/9/2021 11:03 AM, Karl MacMillan wrote: > > Daniel, > > > > > > In terms of optional blocks, Chris and I have argued about optional a > > few times, and part of the reason there's nothing about optional so far > > is because we'd like to solicit community feedback there. My personal > > view is that explicitly marking statements as optional is tedious and > > error prone. But I don't have a really slam dunk "clearly better" > > solution to propose yet at this point. I have a few ideas, but they > > all > > need to be more thoroughly thought out and there are some holes and > > issues to address. I viewed this feature as non-essential for an > > initial proof of concept, and am glad that we can have design > > discussions about it in the open. > > > > So in short, yes, I think the ability to differentiate that certain > > rules are required for a module to work and others are optional is > > definitely needed. But I'm not yet set on what the best way to do that > > is. One key goal here is that a developer of a component should be > > able > > to add policy with fairly minimal knowledge of SELinux. I'd prefer it > > if most of the time they could do the right thing without knowing about > > optional, but I'm not yet sure what the best/cleanest way to achieve > > that will be. > > > > > > Optional blocks have, in practice, been a huge source of errors I > > believe. > > [snip] > > I agree pretty much 100% with everything you've said here about the > usage and historical limitations of optional. Thanks for the added > historical context from before my time. > I am not a fan of optionals either. Disabling optionals has been a source of many bugs in CIL, but it would have been hard to make translating binary modules to CIL work without them. > On the topic of packaging, I'll admit that I'm sparse on details without > an actual implementation at this point, so the packaging aspect of > Cascade is currently vaporware, but my hope is that an integrated > packaging and build system framework, inspired by rust's cargo can solve > a lot of the packaging problems much more cleanly (by inserting optional > blocks for install order problems during compilation rather than in > source for example). > > I like the suggestion of a question mark operator for optional policy > quite a bit. Although I'm really interested in exploring whether it's > possible to just treat the entirety of it as a policy level dependency > resolution problem. Basically annotate with modules a particular module > depends on vs which are optional - the distinction being that the > optional marking is done at the module level rather than the > rule/interface call level. That might be less heavy-weight and error > prone to use while still providing the needed flexibility. > 99% of the time optionals are used as a way of including rules when a module is present without causing an error when it is not, so this should provide everything that is needed. Since you have a lot of freedom, I would recommend a system like that rather than optionals. Jim > > Anyway - forgive me crashing in with all of my opinions. I hope my > > background on the problems of optionals might at least be helpful. > > Opinions are what I'm seeking. :) And yes, I think all of your thoughts > here are quite helpful. I think the attributes concern is a good one > that we aimed to address, and can continue to refine as needed, and the > optional thoughts are extremely helpful, since as I mentioned in my > prior e-mail, the overall support for differentiating which policy is > required and which is optional is a must-have in my view, but how > exactly to specify it in a way that is clear is somewhat challenging and > subjective. Added info on historical context and use cases is a > valuable input to that discussion. > > -Daniel
