[fmac-discuss] MLS and FMAC

[Glenn Faden]

I have some suggestions for combining the existing Solaris MLS
architecture with the MLS attribute in the Flask security context. I want to make it clear that the MLS implementation in Solaris Trusted Extensions and FMAC can complement each other if same basic assumptions are made.

First of all there is the specification of the sensitivity label. The representations for sensitivity labels differ between SELinux and Solaris. The former uses the letter s and a decimal integer to represent the sensitivity level or hierarchical classification, a colon, and one or more instances of the letter c followed by a decimal integer or a range of dot-separated integers. For example:


    s4:c1.c2,c4

In Trusted Extensions this would represented in configuration files as a hexadecimal string:


    0x0004-08-68

Using the default label encoding file, this translates to human-readable label:

CONFIDENTIAL : NEED TO KNOW


We could decide to support both formats, but with appropriate GUI interfaces, this difference can be hidden from the end-user. The maximum number of compartments is configurable in both implementations. In Solaris, the current value is 256, but can be changed without breaking backward compatibility since the structure is opaque outside of the kernel.

Another issue is the support for polyinstantiated directories. Solaris currently relies on zones to polyinstantiate directories like /tmp, /var/tmp, and /export. SELinux relies on a new system call, unshare(2), which creates a new namespace for a process and its descendants. For more details, see:


    http://marc2.theaimsgroup.com/?l=linux-kernel&m=112350785026703&w=2

The zones implementation is more generic than the unshare(2) implementation, so we don't need to implement the Linux solution in Solaris.

Trusted Extensions does not currently store any labels in the underlying filesystem. FMAC requires that each file is labeled with a security context. The obvious solution is to store the current implicit MLS label that Trusted Extensions computes based on the mountpoint label into each file's security context. This would provide an added level of assurance, without introducing any incompatibility.

On the other hand it doesn't provide much additional flexibility unless the mount policy restrictions currently enforced by Trusted Extensions are themselves hooked into Flask. For example, the kernel prevents any mounts that would permit writing down or reading up. It automatically converts read-write mounts to read-only if the label of the zone requesting access dominates the label of the owner of the filesystem. Flask cannot grant access to anything that is denied by the existing MAC policy.

Similarly, some of the inflexible cross-zone MAC policies enforced in the trusted networking code may need to be replaced with calls into Flask. This also applies to doorfs, fifofs, and UNIX domain sockets.

This leads to the question of whether the existing MAC policy enforced by Trusted Extensions should itself be disabled when Flask is disabled or running in permissive mode. In other words, should Trusted Extensions require the use of Flask? Thus far I've considered such flexibility in MLS as a weakness, but I'll leave that question open for discussion.