The TrustedBSD MAC Framework sees its genesis in the observation that trusted op- erating systems efforts frequently start with existing, commercial off-the-shelf (COTS) systems. For example, Trusted Solaris and Trusted IRIX are based on the general- purpose Solaris and IRIX OS products. In addition to life-cycle assurance through improved processes and documentation, OS vendors add operational assurance fea- tures beyond the UNIX baseline. These include enhanced discretionary access control, security event auditing facilities, a decomposition of root privilege into fine-grained privileges, and mandatory access control policies such as multi-level security and the Biba integrity policy.
The MAC Framework is designed to make adding new policy models easier5 by
providing an explicit framework for access control extension – a contract between OS vendor and security extension author. As with most trusted UNIX-based designs, the MAC Framework accepts the UNIX process model, and adapts kernel structures through improvements to access control and other security functionality, rather than migrating to a security kernel. The MAC Framework design also rejects interposition, avoiding concurrency and integration problems observed with system call wrappers.
The framework is a reference monitor: explicit control and notification entry points are scattered throughout security-critical processing in the kernel, and may be instru- mented by policy modules. The framework adopts a number of design philosophies from Hydra [26] including a separation of policy from mechanism and an object-centric ap- proach in which kernel services are considered object providers, and controls are placed on method invocations. An object-centric approach facilitates implementing manda- tory access control policies that are concerned with the flow of information between subjects and objects (such as MLS and Biba). The object-centric perspective also im- poses an ordered view on an often disordered monolithic kernel: it is the responsibility of the kernel and MAC Framework to reconcile many of the abstraction inconsistencies arising in a highly evolutionary kernel implementation, taking care of the book-keeping in order to provide a clean model for policy authors.
The TrustedBSD MAC Framework depends on two fundamental, and essentially non-technical, premises:
1. That extending the access control model of the kernel of a commodity operating system product is a natural, desirable, and inevitable event.
2. That operating system vendors are willing to modify their products to facilitate the goal of extensibility while avoiding common extension problems – perhaps mo- tivated by their own requirements for security extension, and perhaps to support third parties.
The research target for the MAC Framework is the OS vendor, rather than the security extension vendor – a significantly different viewpoint from that taken in most system call interposition approaches.
3.4.1 Guiding principles
The dual goals of explicit access control extensibility and engagement with commodity system vendors lead to a number of philosophical and (at times) programmatic design principles. These principles have, in turn, directed countless implementation choices in the MAC Framework that will be explored throughout the remainder of this chapter:
Do not commit to a particular access control policy. Instead, provide a framework that can support many common models. One need only inspect the broad array of continuing access control research and the variety of access control products to con- clude that there is no wide consensus on a “one true policy” or even “one true policy language”. The practical implication of this design principle is that policies are repre- sented by code, and not data, in the MAC Framework – unlike systems such as type enforcement, which represents flexible policy within the confines of a policy language. With the exception of a small number of static policy characteristics, such as its dis- position with respect to dynamic load and unload, policy modules implement access control decisions and state management functions entirely in C code, offering signifi- cant freedom. This allows policy models to compute results entirely dynamically, or to implement a static policy language such as found in type enforcement (and the SEBSD policy module described in Chapter 4 does precisely this).
Avoid policy-specific intrusions into kernel subsystems. Augment existing kernel services to be aware of the MAC Framework, but attempt to encapsulate policy-specific concerns entirely in policy modules. While the MAC Framework is derived from the requirements of specific policies, avoid leaking of policy-specific data representation or access control approaches outside of the policy modules. An object-centric design facilitates this, capturing many common policy needs in a clean manner.
Provide policy-agnostic infrastructure to avoid code redundancy. Many policies have common infrastructure requirements beyond the selection and provision of instrumen- tation points in the kernel, among which are security labelling (both ephemeral and persistent), APIs for label management, and tracing. Where possible, the MAC Frame- work should provide these facilities, with the dual goals of reducing work for policy authors, and also allowing policy modules to capture only access control-related logic, rather than (for example) file system storage functions for label storage. Provide policy- agnostic APIs so that applications can be security-aware without being policy-specific – for example, by providing policy-agnostic label management APIs.
Policy authors determine their own security and performance trade-offs. While the MAC Framework provides infrastructure for certain heavy-weight policy designs, such as ubiquitous labelling of network packets required by Biba and MLS, many policies may not require those features. As such, the framework should impose the costs of that
infrastructure only on policies that use expensive features, allowing policy authors to explore the design space, and allowing different sites to make different choices regarding performance, functionality, and assurance.
Support multiple simultaneous and independent policies. Most commercial trusted systems include at least two different mandatory access control policies; likewise, if base policies are represented as policy modules, third parties extending the OS will want to use the same policy interfaces to add their own policies. Where possible, provide pre- dictable, deterministic, and ideally sensible, compositions of policies – certain policies will necessarily conflict, but the framework itself should support rather than hinder policy composition. Composition raises potentially tricky questions: for example, how should one policy control subject interactions with another policy’s labels? For exam- ple: if the Biba policy marks an object as HIGH, then a LOW subject should not be able to change the MLS label on the object due as that would violate the integrity policy. The MAC Framework takes the approach that such operations can be controlled, in- troducing a two-phase commit process for subject and object relabel operations, which may interact with multiple policies. This is detailed in Section 3.5.6
Impose structures that facilitate assurance arguments. The MAC Framework acts as a reference monitor, a structure believed to ease assurance arguments by separating pol- icy and mechanism, allowing those aspects of access control to be separately validated. Separation eases auditing of policy implementations, such as determining whether a policy protects all important methods on an object class, and whether the policy pro- tects all desired classes, statically. Having a well-defined set of entry points into the framework, with well-documented semantics (such as locking) makes the framework itself easier to verify using dynamic and static analysis. Similarly, selecting a sensi- ble and deterministic composition policy makes it easier to reason about the effects of combining policies.
Design for an increasingly concurrent operating system kernel. While specifically a security goal, the importance of multiprocessing cannot be understated, especially in light of concurrency vulnerabilities found in system call interposition. In 2000, dual-CPU systems were increasingly common; today, high-end servers and network ap- pliances have dozens of cores, with hundred-core systems on the immediate horizon. This trend shows signs of continuing as CPU designers expose further parallelism to programmers rather than trying to mask it behind superscalar designs, leading in turn to increased exposure of concurrency to operating systems and applications. FreeBSD employs threading techniques extensively within the kernel, as well as providing thread- ing services to user processes6 – the MAC Framework takes advantage of tight kernel
integration by aligning access control check and label maintenance with existing kernel locking, avoiding races otherwise inherent to interposition.
6Since FreeBSD 5.0, userspace threading has changed from an M:N model to a 1:1 model – a
Operating system kernel
Process Process Process
TrustedBSD MAC Framework System call interface
VFS Process signals Socket IPC Biba MLS ... Pipe IPC MAC label system calls
Process MAC Framework
label management APIs support policy- agnostic security label management Kernel subsystems consult MAC Framework to check access control decisions,
and notify the framework of object
life cycle events to support labelling
ugidfw
Policy modules can be compiled into the kernel, loaded at boot, or (where supported by policy
semantics) loaded and unloaded at
runtime
Figure 3.1: The MAC Framework defines four interfaces: the KPI from kernel services to the framework, the API from policy-agnostic user commands to the framework, the KPI between the framework and access control policy modules, and an additional debugging and tracing interface via DTrace probes not shown in this illustration.