On Thu, Nov 4, 2021 at 2:14 PM Daniel Burgener <dburgener@xxxxxxxxxxxxxxxxxxx> wrote: > > We have been working over the past few months on a new high level > language for specifying SELinux policy, in line with the original intent > of CIL, to enable the creation of high level languages that compile into > CIL. > If you ever feel like CIL doesn't quite do what you need or that it doesn't work as expected, please let me know. > Our objective is to create a language that enables the efficient > creation of useful abstractions by policy experts while enabling those > abstractions to be easily usable by non-experts who may contribute to > portions of the policy. > > The design is heavily influenced by Object Oriented principles, with a > goal of enabling the efficient creation of type hierarchies and > eliminating boilerplate through the use of inheritance. The use of > "virtual" types, (which compile into attributes) allows both attribute > like behavior, and also the creation of inherited member functions, > allowing for interfaces as in refpolicy without the redundant > boilerplate. Another key feature is "resource association" which makes > explicit the connections between domains and associated types such as > tmp files. This feature allows for common patterns (such as setting up > a tmp file with a domain transition rule and manage access) to be done > automatically behind the scenes, minimizing the chance of mistakes and > allowing policy developers to focus more on security decisions. > I realize that many of my questions below will be answered with "future work", so don't feel like you need to explain in great detail if that is the case. How different is the inheritance in Cascade as compared to CIL. Obviously, in CIL it is not required, where in Cascade it is a very important part. There is also the use of "this" in Cascade. It seems like Cascade is resolving all of its inheritance before writing out the CIL. My guess is that inheritance is such a core part of Cascade that using CIL's inheritance would make no sense. Is that true? Or did you just not like the way CIL does it? I was surprised that casc only take a single file. Do you expect the policies to be simple enough to do in one file? Since there is only one file, I guess there is no concept of modules for Cascade? And this means there is no need for something like an optional block because all of the policy would be compiled at once? It looks like classes, mls statements, and sids are all automatically created in CIL. Is there a way to specify these things in Cascade or, since these things are almost always the same, are these low-level details something Cascade is not worried about. What about roles and users. I see the keywords, but how are they going to work? Thanks for letting us know about this work. It looks interesting. Jim > The core language functionality is written as a library, which will > hopefully enable the easy creation of associated tooling and plugins > that build on top of that library. It is our hope that this > architecture will assist an expansion of available tooling to aid policy > developers in their work. > > This is still a very early prototype and so some functionality may be > missing or incomplete, but we wanted to make what we have so far > available for community feedback and discussion as we continue development. > > You can find the code and associated documentation at > https://github.com/dburgener/cascade > > I hope this is something that people will find useful and welcome > feedback and contributions as we aim towards the goal of enabling > smoother policy development. > > -Daniel
