by

Vijay Raghavan

The advent of distributed object systems based on CORBA has, quite naturally, thrown up various security related issues. Application developers would like to control accesses to their components across the ORB. This requires the development of a security system that addresses the needs of developers at the granularity they desire. The Cherubim project strives to build such a security system through the use of dynamic policies and active capabilities.

Any security system functions through the enforcement of some kind of security policy. Policies govern what is or is not allowed within the system and under what conditions. Different kinds of security policies exist. The simplest kind, supported in traditional implementations of UNIX, is known as Discretionary Access Control (DAC). At the heart of DAC is an access control matrix that allows users accesses to specific objects in the system. A specialization of DAC is a Double DAC policy that uses matrices with both allowed- and denied- lists. DAC and DDAC can be extended to allow conditional accesses and denials. Non-Discretionary Access Control (NDAC) policies, on the other hand, require the maintenance of access histories within the system in order to monitor the flow of information. Rules that use this information govern accesses. A special kind of NDAC policy is called Mandatory Access Control policy (MAC) wherein the flow of information is controlled by using a collection of hierarchically related domains to group users and system objects. Rules govern the flow of information based on this hierarchy.

Enforcing security policies involves the use of mechanisms that make this enforcement possible. These mechanisms vary from system to system and are closely tied to the system’s representation of security policies. In a traditional operating system, the mechanisms that implement security policies may be thought of as collected in a single component called the ‘reference monitor’. The reference monitor is then thought to contain a ‘Security Policy Decision Function (SPDF)’ that makes decisions based on policy description inputs. Typically, the details of the policy enforced by a system are encoded in its SPDF thus hard-coding the kind of policy implemented.

Developing an infrastructure for secure method invocations across an ORB requires a generic security system that incorporates mechanisms to evaluate policy representations. Such a system should have the flexibility to represent different policy types and to dynamically update policy descriptions. The system should be highly scalable, thus requiring a distributed mechanism for policy evaluation. The Cherubim project achieves these objectives through the use of an object-oriented framework for policy representation.

The object-oriented framework approach uses an existing interpreted object-oriented language (Java) to provide a hierarchy of useful policy-representing classes. The framework’s classes encapsulate the state required to represent policies and evaluate policy decisions. They also provide methods required to actually accomplish the evaluation of these decisions. Policies are described by writing concise programs that use these classes. Policy descriptions are evaluated using the language’s interpreter. This policy description mechanism has the advantage of being easy to develop and, owing to the popularity of Java, highly portable.

As mentioned above, different systems use different mechanisms to implement the evaluation of policy decisions. The object-oriented framework approach facilitates the use of a capability-based mechanism for this purpose. A capability is an entity that a user possesses that proves to the security system that a user is allowed the accesses he/she requests. The user is, by default, denied access to a component unless he/she can prove that such an access is valid. A capability-based mechanism also requires a revocation scheme that ensures that capabilities are invalidated when required.

Cherubim extends the notion of capabilities to entities known as active capabilities. An active capability is more than a mere token that proves a user’s legal status. It is a piece of signed (and hence trusted) code, which when evaluated, returns a user’s access privileges. Further, it enables side-effects that are useful in the decision process.

A user’s access rights are encoded using the policy framework building blocks. The resulting program is signed by a trusted manager and serialized to be passed around. At the receiving end, the signature on the active capability is verified and then the code evaluated. The user can only carry the capability around and pass it on for evaluation. Any tampering with the code invalidates the signature and hence causes the capability to be rejected when presented.

The principles discussed above led to the development of a policy administrator for the distribution and management of active capabilities.

The Cherubim policy administrator is itself a component on an ORB and therefore communicates with the outside world through a well-defined interface. The administrator boasts several useful features.

1. The policy administrator features a user-friendly graphical user interface (GUI). The GUI allows the user (someone wishing to generate a policy for a component) to select the kind of policy desired. DAC and DDAC are currently supported. The input fields change according to the policy type selected. In the context of components on an ORB, the components themselves are treated as system objects and specific methods as operations on system objects. Thus, the developer of a component can create policies that control accesses to specific methods of the component.
2. The administrator permits a user to simultaneously develop policies for several users. Clients’ capabilities are referenced through a hash table and changes are made in the right place. Thus the system allows a user to automatically develop capabilities for each client without having to manually labor through the process. As an additional feature, clients’ names can be obtained from an input file created separately for the purpose. A user would normally wish widespread use of his/her component and therefore create thousands of capabilities. The use of the administrator eases this process.
3. The administrator allows a user to store capabilities in files referenced by the name of the component and of the client for whom the capability is generated along with the kind of policy contained in them. Several capabilities can be maintained for a given component-client pair through the use of user-specified filename extensions. The administrator also keeps track of the most current capability.
4. A user of the administrator may load capabilities from local files or create new capabilities. In both cases the user can make changes to the policy descriptions through the GUI. For example, he/she may add/remove permissions to different methods of a component in a DAC policy. For a DDAC policy, the user may also add/remove denied entries. These denied-entries would override any permissions granted in the policy. The ability to display a text representation of a capability and to evaluate a capability from the GUI aid this development process.
5. The administrator implements a simple interface that allows clients to obtain capabilities and servers to register with the administrator. The functioning of the security system is explained in the next section.

The policy administrator is an important part of the entire security system. For one, it is the primary source of active capabilities for clients wishing to access a given component. Secondly, it assures active revocation of capabilities when required. This is achieved by having various components register with the administrator for every client using the component. The component is immediately informed of any changes.

The administrator communicates with an entity known as an ‘Active Capability Manager (AC manager)’ located transparently at both the client end and the component end. It implements a method called ‘obtain’ which currently takes the name of a component and of a user and returns a string representation of an active capability. This method is invoked by the AC manager in the client in order to obtain a capability. Once the client presents this capability to the corresponding component, the AC manager at the component end registers itself with the policy administrator. The administrator implements a method called ‘register’ that takes the name of the component, the user’s name and an AC manager object. The administrator keeps track of the AC manager through a hash table. The moment the user of the administrator requests that changes to a capability be propagated, this hash table is looked up and the corresponding AC manager’s ‘update’ method invoked, passing it a string representation of the capability.

The next step in the ongoing development effort is to extend the system to allow NDAC and more specifically, MAC, policies. These policies require tracking access histories and this state information should be maintained independent of any changes to the policy rule-base. The policy framework already provides the necessary building blocks. What is required, however, is to develop a separate fail-safe server that maintains state information reliably; one that may be consulted every time an access decision needs to be made. MAC maintains this state information intrinsically through the use of a hierarchical classification of user/component domains. The framework, as it exists now, needs to be extended to encode MAC.

One good way to ease the administration of policies could be to use roles to classify users. Roles are essentially attributes that users are assigned that represent their position in an organization. For example, a user may be assigned the role of a student on a college campus. The use of roles eases the administration of capabilities for users by grouping them together. Roles can also be subclassed, intersected, united etc to create new roles. Hence, the use of roles to administer policies would be the logical next step.