Multilevel security

From Wikipedia, the free encyclopedia

You have new messages (last change).

Multilevel Security (also written as multi-level security or abbreviated as MLS) is the application of a computer system to process information with different sensitivities (i.e. classified information at different security levels), permit simultaneous access by users with different security clearances and needs-to-know, and prevent users from obtaining access to information for which they lack authorization.

MLS allows easy access to less-sensitive information by higher-cleared individuals, and it allows higher-cleared individuals to easily share sanitized documents with less-cleared individuals. A sanitized document is one that has been edited to remove information that the less-cleared individual is not allowed to see. This is often interpreted in different ways:

  • As a security mode: A community whose users have differing security clearances may perceive MLS as a data-sharing capability: users can share information with recipients whose clearance allows receipt of that information. A system is operating in MLS Mode when it has (or could have) connectivity to a destination that is cleared to a lower security level than any of the data the MLS system contains. This is formalized in the Computer Security Intermediate Value Theorem [1]. Determination of security mode of a system depends entirely on the system's security environment; the classification of data it contains, the clearance of those who can get direct or indirect access to the system or its outputs or signals, and the system's connectivity and ports to other systems. Security mode is independent of capabilities, although a system should not be operated in a mode for which it is not worthy of trust.
  • As a security mechanism: Developers of products or systems intended to allow MLS data sharing tend to loosely perceive it in terms of a specific mechanism that enforces data-sharing restrictions, like mechanisms that enforce the Bell-LaPadula model. A system therefore implements MLS if it implements a mechanism that enforces restrictions on sharing classified information, regardless of how effectively it shares information. These mechanisms do not provide direct support of sanitization.

Contents

[edit] Trusted operating systems

An MLS operating environment often requires a highly trustworthy information processing system often built on an MLS operating system, but not necessarily. Most MLS functionality can be supported by a system composed entirely from untrusted computers, although it requires multiple independent computers linked by hardware security-compliant channels (see section B.6.2 of the Trusted Network Interpretation, NCSC-TG-005) [2]. An example of hardware enforced MLS is Asymmetric Isolation. If a single computer is being used in MLS mode, then that computer must use a trusted operating system (OS). Because all information in an MLS environment is physically accessible by the OS, strong logical controls must exist to ensure that access to information is strictly controlled. Typically this involves mandatory access control that uses security labels, like the Bell-LaPadula model noted earlier.

Customers that deploy trusted operating systems typically require that the product complete a formal computer security evaluation. The evaluation is stricter for a broader security range, which are the lowest and highest classification levels the system can process. The TCSEC was the first evaluation criteria developed to assess MLS in computer systems. Under that criteria there was a clear uniform mapping (see CSC-STD-004-85) [3] between the security requirements and the breadth of the MLS security range. Historically few implementations have been certified capable of MLS processing with a security range of Unclassified through Top Secret. Among them [4] were Honeywell's SCOMP, USAF SACDIN, NSA Blacker and Boeing's MLS LAN, all under TCSEC, 1980s vintage and Intel 80386-based. Currently, MLS products are evaluated under the Common Criteria. There are no current systems certified for anything approaching that broad a security range even though certification under the Common Criteria is less rigid today, if anything. Because the Common Criteria decoupled TCSEC's pairing of assurance (EAL level) and functionality (Protection Profile), the clear uniform mapping between security requirements and MLS security range capability documented in CSC-STD-004-85 has largely been lost when the Common Criteria superseded the Rainbow Series.

Freely available implementations of operating systems with limited MLS applicability include Security-Enhanced Linux and TrustedBSD. Security evaluation is a problem for these free MLS implementations for three reasons:

1. It is always very difficult to implement kernel self protection strategy with the precision needed for MLS trust, and these examples were not certified to an MLS protection profile so they may not measure up.

2. Aside from EAL levels, the Common Criteria lacks an inventory of appropriate high assurance protection profiles [5] that specify the robustness needed to operate in MLS mode.

3. Even if 1 & 2 were met, the evaluation process is very costly and imposes special restrictions on configuration control of the evaluated software.

Vendor certification strategies can be misleading to laymen (and even some certifiers!). A common strategy exploits the layman's overemphasis of EAL level with over-certification, such as certifying an EAL 3 protection profile (like CAPP) to elevated levels, like EAL 4 or EAL 5. Another is adding and certifying MLS support features (such as Role-Based Access Control Protection Profile (RBACPP) and Labeled Security Protection Profile (LSPP)) to a kernel that is not evaluated to an MLS-capable protection profile. Those types of features are services run on the kernel and depend on the kernel to protect them from corruption and subversion. If the kernel is not evaluated to an MLS-capable protection profile, MLS features cannot be trusted regardless of how impressive the demonstration looks. Some examples follow:

Sun Microsystems offers Trusted Solaris, a commercial version of the Solaris Operating System that has data labeling functions but is not MLS certified. Early versions were evaluated at the TCSEC B1 level (the lowest allowed for MLS) but more recent versions were evaluated under the Common Criteria at EAL4+, to Controlled Access Protection Profile (CAPP), Role-Based Access Control (RBAC), and Labeled Security protection profiles. [6] The current implementation is based on Solaris 8; Sun has plans for a component called Solaris Trusted Extensions to be added to Solaris 10. These products were not evaluated to an MLS protection profile so their evaluation does not imply MLS capability regardless of the EAL level. CAPP [7] is not an MLS-capable protection profile mainly because it does not address robust kernel self-protection, as noted in its introduction (Section 1.2 on p. 9) which cites the Orange Book category C-2 as its technical basis. C-2 is a system high mode category, not valid for MLS per Table 6 on p. 9 of CSC-STD-004-85 [8].

BAE Systems offers XTS-400, a commercial system that supports MLS at what the vendor claims is "high assurance". Early versions were MLS capable as evidenced by their evaluation at the TCSEC B3 level, but more recent versions were evaluated under the Common Criteria at EAL5+. The protection profile used (CAPP and LSPP, both EAL3 protection profile that are not MLS-capable as discussed above) do not warrant MLS use of this product. Note, however, that in this case, the MLS capability does not spring from the lower assurance protection profiles themselves but from the security target [9] which contains an enriched set of security functionality that do warrant MLS capability.

[edit] MLS problem areas

Sanitization is a problem area for MLS systems. Systems that implement MLS restrictions, like those defined by Bell-LaPadula, only allow sharing when it does not obviously violate security restrictions. Users with lower clearances can easily share their work with users holding higher clearances, but not vice versa. There is no efficient, reliable mechanism by which a Top Secret user can edit a Top Secret file, remove all Top Secret information, and then deliver it to users with Secret or lower clearances. In practice, MLS systems circumvent this problem via privileged functions that allow a trustworthy user to bypass the MLS mechanism and change a file's security classification. However, the technique is not reliable.

Covert channels pose another problem for MLS systems. For an MLS system to keep secrets perfectly, there must be no possible way for a Top Secret process to transmit signals of any kind to a Secret or lower process. This includes side effects such as changes in available memory or disk space, or changes in process timing. When a process exploits such a side effect to transmit data, it is exploiting a covert channel. It is extremely difficult to close all covert channels in a practical computing system, and it may be impossible in practice. The process of identifying all covert channels is a challenging one by itself. Most commercially available MLS systems do not attempt to close all covert channels, even though this makes it impractical to use them in high security applications.

Bypass is problematic when introduced as a means to treat a system high object as if it were MLS trusted. A common example is to extract data from a secret system high object to be sent to an unclassified destination, citing some property of the data as trusted evidence that it is 'really' unclassified (e.g. 'strict' format). A system high system cannot be trusted to preserve any trusted evidence, and the result is that an overt data path is opened with no logical way to securely mediate it. Bypass can be risky because, unlike narrow bandwidth covert channels that are difficult to exploit, bypass can present a large, easily exploitable overt leak in the system. Bypass often arises out of failure to use trusted operating environments to maintain continuous separation of security domains all the way back to their origin. When that origin lies outside the system boundary, it may not be possible to validate the trusted separation to the origin. In that case, the risk of bypass can be unavoidable if the flow truly is essential.

A common example of unavoidable bypass is a subject system that is required to accept secret IP packets from an untrusted source, encrypt the secret userdata and not the header and deposit the result to an untrusted network. The source lies outside the sphere of influence of the subject system. Although the source is untrusted (e.g. system high) it is being trusted as if it were MLS because it provides packets that have unclassified headers and secret plaintext userdata, an MLS data construct. Since the source is untrusted, it could be corrupt and place secrets in the unclassified packet header. The corrupted packet headers could be nonsense but it is impossible for the subject system to determine that with any reasonable reliability. The packet userdata is cryptographically well protected but the packet header can contain readable secrets. If the corrupted packets are passed to an untrusted network by the subject system they may not be routable but some cooperating corrupt process in the network could grab the packets and acknowledge them and the subject system may not detect the leak. This can be a large overt leak that is hard to detect. Viewing classified packets with unclassified headers as system high structures instead of the MLS structures they really are presents a very common but serious threat.

Most bypass is avoidable. Avoidable bypass often results when system architects design a system before correctly considering security, then attempt to apply security after the fact as add-on functions. In that situation, bypass appears to be the only (easy) way to make the system work. Some pseudo-secure schemes are proposed (and approved!) that examine the contents of the bypassed data in a vain attempt to establish that bypassed data contains no secrets. This is not possible without trusting something about the data such as its format, which is contrary to the assumption that the source is not trusted to preserve any characteristics of the source data. Secure bypass is a myth, just as a so-called "High Assurance Guard (HAG)" that implements bypass. The high risk these introduce should be acknowledged. There is no way to know how much classified information is taken from our systems by exploitation of bypass.

[edit] MILS architecture

MILS (multiple independent levels of security) is an architecture that addresses the domain separation component of MLS. Security models such as the Biba model (for integrity) and the Bell-LaPadula model (for confidentiality) allow one-way flow between certain security domains that are otherwise assumed to be isolated. MILS addresses the isolation underlying MLS without addressing the controlled interaction between the domains addressed by the above models. Trusted security-compliant channels mentioned above can link MILS domains to support more MLS functionality.

The MILS approach pursues a strategy characterized by an older term, MSL (multiple single level), that isolates each level of information within its own single-level environment (System High).

The rigid process communication and isolation offered by MILS may be more useful to ultra high reliability software applications than MLS. MILS notably does not address the hierarchical structure that is embodied by the notion of security levels. As such, MILS might as well be called Multiple Independent Domains of Security. MLS on MILS would require a complex structure of trusted (and certified) applications to emulate an MLS operating environment for other applications. By declining to directly address interaction among levels implied by this hierarchical structure, MILS is simpler to implement but also lacks the richness and flexibility expected by practical MLS applications.

[edit] MSL systems

There is another way of solving such problems known as Multiple Single-Level. Each security level is isolated in a separate untrusted domain. The absence of medium of communication between the domains assures no interaction is possible. The mechanism for this isolation is usually physical separation in separate computers. This is often used to support applications or OSs which have no possibility of supporting MLS such as MS Windows and Solaris.

[edit] See also

[edit] Further reading

Retrieved from "http://en.wikipedia.org../../../m/u/l/Multilevel_security.html"