RFE: add MLS support to scripts/selinux/mdp

[pcmoore]

With the popularity of MCS it's virtualization/container policy based on sVirt, it would be nice to add MLS support to the scripts/selinux/mdp tool in the kernel.

[pcmoore]

See related issue #45.

[stephensmalley]

Does anyone use mdp? I don't think it is useful in its current form. You can't use it to even do regression testing of SELinux since selinux-testsuite depends on Fedora/refpolicy-based policies in a variety of ways. And it doesn't provide a good starting point for a new policy since it only generates a single type, has no macros, etc, so anyone writing a new policy would have to look elsewhere (e.g. refpolicy, Android sepolicy, the original example policy). Maybe if scripts/selinux contained a minimalist TE policy with some macros, at least two domains (kernel and init), etc and mdp just generated the boilerplate prefix and postfix, it might be useful. The fs_use_* rules really ought to be generated based on the set of configured filesystems. If we could get to the point where selinux-testsuite worked with the mdp-generated policy, that would be nice too, but that's a lot of work.

[pcmoore]

Does anyone use mdp? I don't think it is useful in its current form.

I'm not sure, but my guess is "no", which is part of my concern. A mdp generated policy is always going to be overly simplistic, but I think it should be possible to create a working, full-featured (e.g. provides MLS) SELinux policy for use as a starting point or example.

You can't use it to even do regression testing of SELinux since selinux-testsuite depends on Fedora/refpolicy-based policies in a variety of ways.

I think using the mdp policy as a base for the selinux-testsuite is not a realistic goal at this point. Of course it is possible, and in some ways it would be nice to have that ability, but that is effort that I think could be better spent elsewhere right now.

And it doesn't provide a good starting point for a new policy since it only generates a single type, has no macros, etc, so anyone writing a new policy would have to look elsewhere (e.g. refpolicy, Android sepolicy, the original example policy).

I think it could be a good starting point for a new policy as a simplistic example of the bare minimum needed to get a working SELinux policy. While I agree that having at small number of domains could be beneficial to demonstrate transitions and interactions, even having just a single domain with all of the necessary support and definitions in place is helpful.

Maybe if scripts/selinux contained a minimalist TE policy with some macros, at least two domains (kernel and init), etc and mdp just generated the boilerplate prefix and postfix, it might be useful.

I agree that would be a nice addition. I don't think it removes the need for this feature request, in fact I think adding MLS support to mdp would make the approach you describe much more useful.

The fs_use_* rules really ought to be generated based on the set of configured filesystems.

Agreed.

If we could get to the point where selinux-testsuite worked with the mdp-generated policy, that would be nice too, but that's a lot of work.

Agreed, and not something I think is worth spending a lot of time on at this point. Maybe at some point in the future, but not now.

[stephensmalley]

To generate a MLS policy that can be compiled via checkpolicy -M, the output of mdp -m would need to be augmented to include:

• at least one sensitivity declaration (ala "sensitivity s0;")
• a dominance definition ordering the sensitivities (ala "dominance { s0 }")
• optionally any category declarations (ala "category c0;") - not strictly required
• a level declaration per sensitivity with its allowable categories (ala "level s0:c0;")
• at least one mls constraint (ala "mlsconstrain file { read write } (l1 eq l2 and h1 eq h2);"), possibly auto-generated for every class/permission as with the class definitions,
• a default level and allowable range definition for each user declaration (appended to the existing user declaration, ala "level s0 range s0 - s0:c0" appended to the user declaration),
• a level/range field for every security context (appended to every security context in both the policy and the file_contexts, ala ":s0" appended to each security context in an initial sid, fs_use_* or file contexts entry).

Not clear what if anything you could do with it when you're done; if you don't define any mls constraints you won't be restricted in any way by mls and if you require equivalence for all permissions you won't be able to start a process in another level/range.

[stephensmalley]

Like this un-tested patch,
stephensmalley@e6c52bc

[stephensmalley]

By un-tested, I mean I didn't try to load the resulting policy. But it did compile ok with checkpolicy -M, and setfiles -c policy.31 file_contexts passed. Logins would probably break though; should probably switch the default level for user_u to just s0 there. Even then, you wouldn't be able to switch to another category if enforcing since it requires equivalence for all permissions and no types are exempted (and since we only have one type, we can't exempt that without effectively disabling mls altogether). So I don't know what use it would have.

[stephensmalley]

Fixed up the default level and a few nits in stephensmalley@7245f3c

[pcmoore]

We have basic MLS support now in mdp, so I'm going to close this out.