What is the purpose of classorder and sidorder?

[danderson]

CIL has classorder and sidorder statements, and seems to require ordering of all classes and SIDs declared in the policy. However I couldn't find any explanation as to why these statements exist. They appear to be unique to CIL and have no equivalent that I could find in the kernel policy language, and I couldn't find any documentation about semantics.

Why do classorder and sidorder exist?

Why do classes and SIDs need to be put in a specific order?

What happens if I swap the order of two classes/SIDs?

If this ordering is required, how does the kernel language and Reference Policy m4 language express it?

Thanks in advance!

[jwcart2]

The ordering of some rules matters for the kernel policy. Historically the order that classes, sids, and categories appeared in the policy (policy.conf or Refpolicy) determined their ordering in the kernel binary policy. For categories, this ordering is used to resolve a category range. It used to be required for a policy to list classes and sids in the exact order the kernel did.

When CIL was created the ordering for classes was still required, but we did not want ordering based on the order the rules appeared (because we wanted to be able to break up policy into multiple files without caring about the order that the CIL compiler saw them), so we created ordering rules to allow the order to be specified. In CIL there can be multiple ordering rules and CIL will try to piece them together into one ordering. If it can't or if the ordering rules allow an ambiguity, then an error will be given.

The order rule would not strictly be needed any more for classes, but we left it in for compatibility. For sensitivities, the order rule replaces the dominance rule. For categories, the order rule is still needed to later calculate category ranges.

[danderson]

Thank you! The key parts I was missing, I think, is that in the binary policy some list orders are/used to be load-bearing; and that in the original kernel policy language, that order is defined implicitly by source text order.

Using explicit ordering declarations in CIL representation makes complete sense, now that I see they're just a more obvious/composable expression of an existing behavior.

And to confirm, on modern kernels SIDs can also be put in an arbitrary order without matching the kernel, correct? At least that's my reading of https://github.com/torvalds/linux/blob/499551201b5f4fd3c0618a3e95e3d0d15ea18f31/security/selinux/ss/policydb.c#L858, the binary policy encodes a list of {sid, context} pairs rather than rely on any kernel array indices.