Redefining system's base declarations.

[TheMarshalMole]

Hello,

The resulting .CIL of a .CAS file has the definition all of the system's base classes, such as: "alg_socket", "anon_inode".
This monolithic approach is problematic because the resulting .CIL require manual editing before being insert in the SE's Binary Tree of policies.

I understand why this approach is desired, but shouldn't be any compilation option to disable these embeddings?

Thank you for your support,
Cristian

[dburgener]

Cristian, thanks for reaching out.

I agree 100%. The current hardcoded approach of automatically generating all the system object classes is expedient in the short term, but not ideal. I think that many users will appreciate the simplicity of this common case, but Cascade does need to support specification here. There are some other goals that I view as more significant in the near term (see ROADMAP.md), but I definitely want to support customization of this in the future.

This monolithic approach is problematic because the resulting .CIL require manual editing before being insert in the SE's Binary Tree of policies.

Can you clarify a little more exactly what problem you're experiencing? Generally having object classes not recognized by object managers should not be a problem, the object managers will simply never query the policy on those classes. Not having needed object classes on the other hand is certainly a problem. I'm aware that the current Cascade compiler doesn't supply userspace object classes, but the kernel classes should generally be what is expected by a modern kernel, and an older kernel shouldn't experience problems with the declaration of classes that don't exist for that kernel.

If you can clarify the exact symptoms you are experiencing a little more that would be helpful both in terms of refining sensible defaults for users who desire automatic object class generation, as well as the specific details on what manual object class specification should look like.

[TheMarshalMole]

Daniel, thank you for your fast response!

There are some other goals that I view as more significant in the near term (see ROADMAP.md), but I definitely want to support customization of this in the future.

Would it be possible, instead of having them hardcoded, to obtain those definitions from the system via HLL utility during .CAS compile?

Can you clarify a little more exactly what problem you're experiencing? Generally having object classes not recognized by object managers should not be a problem, the object managers will simply never query the policy on those classes.

The problem is that the object classes are already defined on the system, and an error is thrown for "redefining the classes". Or at least this is what is happening on CentOS 8.X.

[dburgener]

It sounds like what you're doing is attempting to write a single policy module in Cascade and load it into an existing system policy. Is that correct?

If that's the case, then that is not yet a supported feature. It's on the roadmap for the 1.0 release. The current focus has been on building complete system policies in Cascade and getting that working well.

If you wanted to submit a PR that added a --module argument to casc to build the Cascade file as policy module, with the initial functionality of that as not including object class definitions, I would likely take that. If that's not something you're interested in, it's something I would plan on getting to at some point as well, but probably not for another month or two.