Check out the new USENIX Web site. next up previous
Next: Encapsulation of Security Labels Up: Integrating Flexible Support for Previous: Introduction

   
Security Architecture

This section provides an overview of the Flask architecture and the SELinux implementation of the architecture. The Flask architecture provides flexible support for mandatory access control policies. In a system with mandatory access controls, a security label is assigned to each subject and object. All accesses from a subject to an object or between two subjects must be authorized by the policy based on these labels. The Flask architecture cleanly separates the definition of the policy logic from the enforcement mechanism. The security policy logic is encapsulated within a separate component of the operating system with well-defined interfaces for obtaining security policy decisions. This separate component is referred to as the security server due to its origins as a user-space server running on a microkernel. In the SELinux implementation, the security server is merely a kernel subsystem.

Components in the system that enforce the security policy are referred to as object managers in the Flask architecture. Object managers are modified to obtain security policy decisions from the security server and to apply these decisions to label and control access to their objects. In the SELinux implementation, the other kernel subsystems (e.g. process management, filesystem, socket IPC, System V IPC) are object managers. Application object managers can also be supported, such as a windowing system or a database management system.

The Flask architecture also provides an access vector cache (AVC) component that stores the access decision computations provided by the security server for subsequent use by the object managers. The AVC component also supports revocation of permissions, as described later in Section 2.4. An object manager may further reduce the cost of a permission check by storing references to the appropriate entry in the AVC with its objects. As a result, most permission checks can occur without even incurring the cost of an extra function call.

The remainder of this section further elaborates on the Flask architecture and its SELinux implementation. It begins by discussing how security labels are encapsulated in Flask. This section then discusses how Flask supports flexibility in labeling and access decisions. The ability of Flask to support policy changes is then described.



 
next up previous
Next: Encapsulation of Security Labels Up: Integrating Flexible Support for Previous: Introduction
Stephen D. Smalley
2001-04-26