The Flask Security Architecture: System Support for Diverse Security Policies Ray Spencer (Secure Computing Corporation) Stephen Smalley, Peter Loscocco (National Security Agency) Mike Hibler, David Andersen, Jay Lepreau (University of Utah) Abstract tributed environments of today, this policy flexibility must be supported by the security mechanisms of the operating Operating systems must be flexible in their support for system [33]. security policies, providing sufficient mechanisms for sup- porting the wide variety of real-world security policies. Supporting policy flexibility in the operating system is a Such flexibility requires controlling the propagation of ac- hard problem that goes beyond just the supporting of multi- cess rights, enforcing fine-grained access rights and sup- ple policies. The system must be capable of supporting fine- porting the revocation of previously granted access rights. grained access controls on low-level objects used to per- Previous systems are lacking in at least one of these ar- form higher-level functions controlled by the security pol- eas. In this paper we present an operating systems secu- icy. Additionally, the system must ensure that the propaga- rity architecture that solves these problems. Control over tion of access rights is in accordance with the security pol- propagation is provided by ensuring that the security pol- icy. Lastly, policies are not, in general, static. To cope with icy is consulted for every security decision. Both fine- policy changes or dynamic policies, the system must have a grained access rights and revocation support are provided mechanism for the revocation of previously granted access by mechanisms that are directly integrated into the service- rights. Earlier systems have provided mechanisms that al- providing components of the system. The architecture is low several security policies to be supported, but they are described through its prototype implementation in the Flask inadequate to generally support policy flexibility because microkernel-based operating system, and the policy flexi- they fail to address at least one of these three areas. bility of the prototype is evaluated. We present initial ev- This paper describes an operating system security archi- idence that the architecture’s impact on both performance tecture that demonstrates the feasibility of policy flexibility. and code complexity is modest. Moreover, our architecture This is done by presenting its prototype implementation, is applicable to many other types of operating systems and the Flask microkernel-based operating system, that success- environments. fully overcomes these obstacles to policy flexibility. The 1 Introduction cleaner separation of mechanism and policy specified in the security architecture enables a richer set of security policies A phenomenal growth in connectivity through the Inter- to be supported with less policy-specific customization than net has made computer security a paramount concern, but has previously been possible. Flask includes a security pol- no single definition of security suffices. Different comput- icy server to make access control decisions and a framework ing environments, and the applications that run in them, in the microkernel and other object managers in the sys- have different security requirements. Because any notion of tem to enforce those access control decisions. Although the security is captured in the expression of a security policy, prototype system is microkernel-based, the security mecha- there is a need for many different policies and even many nisms do not depend on a microkernel architecture and will types of policies [1, 44, 49]. To be generally acceptable, easily generalize beyond it. any computer security solution must be flexible enough to The resulting system provides policy flexibility. It sup- support this wide range of security policies. Even in the dis- ports a wide variety of policies. It controls the propagation This research was supported in part by the Defense Advanced Re- of access rights by ensuring that the security policy, through search Projects Agency, monitored by the Department of the Army under a consistent replica, is consulted for every access deci- contract number DABT63–94–C–0058, and the Air Force Research Labo- sion. Enforcement mechanisms, directly integrated into the ratory, Rome Research Site, USAF, under agreement number F30602–96– service-providing components of the system, enable fine- 2–0269. It is also supported in part by the Maryland Procurement Office, contract MDA904-97-C-3047. grained access controls and dynamic policy support that al- Contact information: [email protected], Secure Comput- lows the revocation of previously granted access rights. Ini- ing Corp., 2675 Long Lake Road, Roseville, MN 55113-2536; sds,- tial performance results, as well as statistics on the scale pal ¡ @epoch.ncsc.mil, National Security Agency, 9800 Savage Rd, Ft and invasiveness of the code changes, indicate that the im- Meade, MD 20755-6534; pact of policy flexible security on the system can be kept to mike,danderse,lepreau ¡ @cs.utah.edu, Dept. of Computer Science, 50 S. Central Campus Drive, Rm. 3190, University of Utah, SLC, UT 84112- a minimum. 9205. http://www.cs.utah.edu/projects/flux/fluke/html/flask.html Draft, March 1999 The remainder of the paper begins by elaborating on the that may be injected by the security policy, and permits meaning of policy flexibility. After a discussion of why two some system state to exist beyond the scope of the security popular mechanisms employed in systems to provide secu- policy. In actuality, however, each of these apparent lim- rity are limiting to policy flexibility, some related work is itations is a desirable property since many of the internal described. The Flask architecture is then presented through operations and state of any system are of no apparent use or a discussion of its prototype design and implementation. concern to any security policy. Section 6.1 will discuss how The paper concludes with an evaluation of the policy flexi- these limitations were interpreted for the Flask system. bility of the system, an assessment of the performance im- A system that is policy flexible must be capable of sup- pact, and a discussion of the scale and invasiveness of the porting a wide variety of security policies. Security poli- Flask changes. cies may be classified according to certain characteristics, including such things as: the need to revoke previously 2 Policy Flexibility granted accesses, the type of input required to make access decisions, the sensitivity of policy decisions to external fac- When first attempting to define security policy flexibil- tors like history or environment, and the transitivity of ac- ity, it is tempting to generate a list of all known security cess decisions [44, Section 6]. The remainder of this section policies and define flexibility through that list. This ensures focuses on revocation, which is the most difficult of these that the definition will reflect a real-world view of the de- characteristics to support. gree of flexibility. Unfortunately, this simplistic definition is unrealistic. Real-world security polices in computer sys- Since even the simplest security policies undergo change tems are limited by the mechanisms currently provided in (e.g. as user authorizations change), a policy flexible sys- such systems, and it is not always clear how security poli- tem must be capable of supporting policy changes. Since cies enforced in the “pencil-and-paper” world translate to policy changes may be interleaved with the execution of computer systems, if at all [3, 49]. As such, a more useful controlled operations, there is the risk that the system will definition is needed. enforce access rights according to an obsolete policy. Thus, there must be an effective atomicity in the interleaving of It is more useful to define security policy flexibility by policy changes and controlled operations. viewing a computer system abstractly as a state machine performing atomic operations to transition from one state The fundamental difficulty in achieving this atomicity to the next. Within such a model, a system could be consid- is ensuring that previously granted permissions can be re- ered to provide total security policy flexibility if the security voked as required by a policy change. When a permission policy can interpose atomically on any operation performed is to be revoked, it is necessary for the system to ensure by the system, allowing the operation to proceed, denying that any service controlled by the permission will no longer the operation or even injecting operations of its own. In be provided by the system unless the permission is granted such a system, the security policy can make its decisions again later. Revocation can be a very difficult property to using knowledge of the entire current system state, where satisfy because permissions, once granted, have a tendency the current system state can be considered to encompass to migrate throughout the system. The revocation mecha- the history of the system. Because it is possible to interpose nism must guarantee that all of these migrated permissions on all access requests, it is possible to modify the existing are indeed revoked. security policy and to revoke any previously granted access. A basic example of a migrated permission surfaces in This second definition more correctly captures the Unix. The access decision for writing to a file is performed essence of policy flexibility, but practical considerations when that file is opened, and the granted permission is force a slightly more limited point of view. It is unlikely cached in the file description for efficient validation of write that a real system could base security policy decisions for access during write operations. Revoking write access to all possible operations on the entire current system state. that file in Unix only prevents future attempts to open the Instead, a more realistic approach is to identify that portion file with write access and has no effect on the migrated per- of the system state that is potentially security relevant and missions in existing file descriptions.