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. -- gpg --locate-keys dominick.grift@xxxxxxxxxxx Key fingerprint = FCD2 3660 5D6B 9D27 7FC6 E0FF DA7E 521F 10F6 4098 https://sks-keyservers.net/pks/lookup?op=get&search=0xDA7E521F10F64098 Dominick Grift
