On Fri, Aug 7, 2020 at 12:39 PM Stephen Smalley <stephen.smalley.work@xxxxxxxxx> wrote: > > 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. Oh, I see; it is to allow validation of e.g. cN.cM notation. So that's a comparison within a context, not between two different contexts.
