On Fri, Aug 7, 2020 at 12:04 PM Dominick Grift <dominick.grift@xxxxxxxxxxx> wrote: > > Stephen Smalley <stephen.smalley.work@xxxxxxxxx> writes: > > > On 8/7/20 10:40 AM, Richard Haines wrote: > > > >> This is an RFC patch to get some feedback as: > >> 1) Table 1 is now a pipe table, however it still has <br> codes to > >> break up the text. Also updated styles.html.css to match the pdf version > >> to allow correct HTML rendering. > >> 2) Table 2 is now a pipe table with updated text. > >> > >> Add a TOC to aid navigation > >> Add text to clarify MCS/MLS > >> > >> Signed-off-by: Richard Haines <richard_c_haines@xxxxxxxxxxxxxx> > >> --- > >> > >> @@ -48,6 +56,18 @@ The sections that follow discuss the format of a security level and > >> range, and how these are managed by the constraints mechanism within > >> SELinux using dominance rules. > >> +### MLS or MCS Policy > >> + > >> +From an SELinux perspective: > >> + > >> +- An MLS policy has more than one security level with zero or more categories. > >> + It is generally used in systems that require the 'Read Down' and 'Write Up' > >> + services, whether it be for files, network services etc.. > >> +- An MCS policy has a single security level with zero or more categories. > >> + Example uses are virtualization (see the > >> + [**Virtual Machine Support**](vm_support.md#selinux-virtual-machine-support) > >> + section) and container security. > >> + > > > > To be clear, SELinux (i.e. the code/mechanism) only knows of MLS, > > i.e. it has a MLS engine in the security server and a MLS portion of > > the policy configuration that drives that engine. That MLS engine has > > been leveraged by two different types of policies, the original MLS > > configuration modeled after Bell-LaPadula and the later-introduced MCS > > configuration (which underwent a fundamental transformation from being > > user-facing and somewhat discretionary to being a transparent > > isolation mechanism for sandbox, container, and virtualization > > runtimes). The number of sensitivities, number of categories, and the > > set of MLS constraints used to determine whether a permission is > > allowed are entirely up to the policy author. A level in SELinux is a > > combination of a hierarchical sensitivity and a non-hierarchical > > (potentially empty) category set. In practice MCS is used for simple > > isolation and therefore doesn't employ sensitivities since there is no > > hierarchical relationship to be enforced. > > > > > > Compartments might not be hierarcical in the sense of dominance but if > there was no hierarchy then I would argue the there would not be a need > for categoryorder. In the policy.conf language, there is a dominance statement that specifies the hierarchical ordering of sensitivities. There is no equivalent for categories, and the kernel never compares category pairs for any kind of >, =, or < relationship; it only compares subset comparisons between two category sets. So there is no hierarchy. If CIL defines a categoryorder, then that's unnecessary.
