Specification of Management Policies Damian A. Marriott
[email protected]
Masoud Mansouri-Samani
[email protected]
Morris S. Sloman
[email protected]
1 Introduction The aim of this work is to provide a framework for specifying management policies within distributed systems. Domains (Becker, Sloman and Twidle, 1993) are used to group objects together for management purposes in an effort to cope with the size and complexity of the task of distributed systems management. Policies are viewed as relationships between subject and target objects, and may represent obligations and authorisations. This report builds on previous work which has been presented earlier (Sloman, 1993), and introduces a system architecture and policy language format, and provides some example policies.
2 System Architecture Management policies are specified in terms of domains, using domain scope expressions (Becker et al., 1993), and require the support of a domain service to be implemented. There are two modes of policy able to be specified, obligation and authorisation, and the architectural support required for each of these differs. The conditions under which obligation policies are to be performed can be specified in terms of events which are provided by a monitoring service. In addition, support is required for the management of the management policies themselves. These services and supports are described in the following sections, and then an overview is presented of how an automated manager interacts with them.
2.1 Domain Service The domain service allows the grouping of objects and provides a means of determining the members of these groups, or domains. Managers determine the objects they are to manage using the domain service, but perform management operations on the objects themselves (without use of the domain service). Scope expressions represent sets of objects, and allow union, difference and intersection operators over domains and objects. For example, D1 ? O3 D4 represents the set of objects consisting of those in domains D1 and D4 , excluding object O3 (a shorthand is used such that O3 represents the set containing O3 ).
+
Presented at DSOM ’94 workshop, 10–12 October, 1994.
1
2.2 Monitoring Service Managers, automated or otherwise, should be able to receive monitoring information (in the form of event and status reports) from various sources and use it to perform the appropriate actions as specified in policies. A general monitoring service is needed to provide the following functionalities:
filtering of unwanted reports which are generated by various objects in the system; correlation of monitoring information (event and status data) from one or more sources and hence, raising the level of abstraction of this data; dissemination of monitoring information to one or more destinations. This is useful, for example, when several managers are interested in the same type of event.
Event-driven monitoring is concentrated on here, and a rule-based language called GEM (Generalised Event Management language) (Mansouri-Samani, 1993) is used to implement a monitoring server which can receive event reports from various sources and perform filtering and correlation (see Section 3.4).
2.3 Obligation Policy Support An obligation policy defines what activities a subject must (or must not) do, and represents a duty or responsibility to achieve some goal or task. Conceptual examples of obligation policies are “archiver should backup department’s files every night” and “company director should protect company’s assets”. The implementation of obligation policies is distributed among automated managers which interpret policies. Obligation policies on human subjects may be implemented through a suitable interface which advises users of their obligations. Negative obligation policies override positive ones and act as filters on which policies to apply. Being obliged by an obligation policy to do an activity does not does not imply the authorisation to perform it. If applicable, this must be specified as a separate authorisation policy. An automated manager can be built using libraries of functions common to all automated managers operating within this framework. These functions include interfacing with the domain, monitoring and policy management services and objects (via their management interfaces), and processing event and state reports and interpreting event expressions.
2.4 Authorisation Policy Support An authorisation policy defines what activities a subject is permitted (or forbidden in the case of negative authorisation) to do in relation to a set of target objects. A reference monitor is the authorisation policy enforcer. Negative authorisation policies override positive ones, with the default authorisation for an action being negative, or forbidden. It should not be possible for actions, which are specified in authorisation policies, to be performed except via the reference monitor associated with the target concerned. In this way the reference monitor can ensure that only authorised actions take place. 2
A reference monitor needs to be highly trusted by those whose objects are under its control. In addition, the information on which it bases its decisions must also be able to be trusted. This includes being able to authenticate the subjects attempting actions, trusting the domain service to resolve the subjects of authorisation policies, providing a means to provide trustworthy event and state information, and trusting the process of creating and maintaining authorisation policies.
2.5 Policy Management Support The policy management support covers tools for creating and querying policies, and a service for enacting policies. The policies themselves are viewed as objects, following the object oriented philosophy. Since the implementation of obligation policies is distributed among the automated managers, there needs to be support for keeping the policies they are implementing up-to-date. This not only refers to keeping pace with any changes in policies, but also any changes brought about by changes in domain memberships. The membership of domains is important to policies that are specified in terms of domains (rather than objects), since they apply to objects within those domains and may need to vary in their application accordingly. For authorisation policies this involves maintaining access control entries (ACEs) with target objects, and methods for dealing with this are the subject of current research (Yialelis and Sloman, 1994). For obligation policies there is a similar situation which involves maintaining policies with subject objects. High-level and abstract policies can be represented and then refined into lower-level policies. The policy management system should support this hierarchy and allow it to be used for such purposes as tracing the sources of two conflicting policies.
2.6 Overview of Automated Manager Interactions The diagram in Figure 1 shows how an automated manager interacts with the various components of a system to implement an obligation policy. The following steps are involved in setting up an obligation policy: 1. an authorised user enacts a new obligation policy via the policy management service (PMS); 2. the PMS queries the domain service in order to determine the subjects specified in the subject domain scope expression; 3. the PMS propagates the policy to these objects (automated managers); 4. the managers register with the monitoring service to receive the event specified in the condition; 5. the monitoring service begins monitoring for the event registered, which may include monitoring target objects, the system and the manager itself. Once a relevant event has been detected by the monitoring service, the following steps involving a manager occur: 1. the monitoring service notifies the manager of the occurrence of the event; 3
2. the manager checks the specified constraint is satisfied, possibly querying the system and target objects (which are determined by querying the domain service); 3. for each of the target objects which satisfy the constraint, the manager performs the specified action on them.
Policy Management Service
Automated Manager
Domain Service
Monitoring Service System
Target Objects
Figure 1: Interactions of an automated manager.
3 Policy Format The five attributes of policy, mode, subject, target, activity (consisting of condition and action) and constraint, are used for specifying management policies (Becker et al., 1993). In addition each policy has its own identifier. These are expanded upon in the following, and some example policies using this format are given in Section 4. The general format of a policy is given below with optional constructs within brackets. policy id mode [ condition ] subject f action g [ target ] [ when constraint ] ;
3.1 Mode The mode of a policy may be either obligation or authorisation, both of which may be in a positive or negative sense. The mode of a policy is given by either an O, denoting an obligation policy, or an A, denoting an authorisation policy, with either a or a ? appended, denoting a positive or negative policy respectively, e.g. A denotes a mode of positive authorisation.
+
4
+
3.2 Subject The subject of a policy defines those objects which are to be obliged or authorised to perform the activity specified, for example, users and automated managers. It is specified as a list of domain scope expressions which each may specify a set of explicit objects (typically one) or alternatively a subject scope in terms of domains (and possibly objects as well) where membership is indeterminate at the time of policy specification. The use of a subject scope allows the applicability of a given policy to alter with the domain memberships referred to in that scope. This ability is useful, for example, in the case of policies that are specified in terms of roles rather than explicit users, where a role is a domain whose membership may change in time as different users within an organisation occupy it. Each scope expression may have an optional label for enabling easy reference to each subject or target expression within the policy statement, of the form “label:expression” (see Section 4 for some examples). By default, a subject scope expression in a policy refers to all subjects denoted by that expression, however, there may also be policies which are only required to be applied to a fixed number of subjects (most likely one). This can be denoted in the constraint field of a policy (see Section 3.5).
3.3 Target The target or targets of a policy are objects on which the activities specified by the policy are performed, for example, files, printers and users. They are specified in a similar fashion to subjects using domain scope expressions. The target field of a policy may be omitted where there is no specific target as it may be implicit, e.g. when a policy is at a high level of abstraction, such as in the policy “system administrator should ensure system is well maintained”.
3.4 Activity The activity of a policy is defined by two parts, an optional condition and an action. An action defines what is to be done for obligations what is to be permitted to be done for authorisations. It consists of target method invocations, and may list different methods for different target object types. For example, different types of storage devices may have different reset capabilities: cdrom: stop(), tape: rewind() A condition defines when an obligation should be performed. It is not a valid field for an authorisation policy. In general, a condition may be defined in terms of a set of events (expressed using an event expression), a predicate on the state, or a combination of both. Currently concentration is being placed on relatively simple event-based conditions which will be relying on a generalised monitoring service for notifications of relevant events and for the composition of more complex events. The format of an event expression is defined by GEM. In GEM an event expression in its simplest form consists of an event class name which specifies a primitive event, for example, invalid login or software installed. These are declared using a simple notation, as in the following for invalid login: 5
event invalid login(int user id); An event declaration identifies any event dependent attributes which are associated with this class of primitive events. Various time events can also be specified as primitive events. The simple events able to be specified in the policy language are primitive events and two types of time events. Some examples follow.
primitive event, e.g. on invalid login time point event, e.g. at [23:00] at [15:00 10/Oct/1994]
/* at 23:00 (every night) */ /* once off specific point in time */
time period event, e.g. every [20 min] every [3 day 12 hour]
+
/* every twenty minutes */ /* every three and half days */
In addition to an event class identifier, the following event independent attributes are assumed to be included in every event notification generated by various objects:
a physical time stamp (denoted @); a logical time stamp (used to discriminate between events for which the other attributes are identical) (denoted #); and a source identifier (denoted $).
These provide the minimum amount of information that is necessary to uniquely identify the occurrence of an event in a distributed environment. They can be accessed using special unary operators (as indicated in parentheses above). An optional guard can be associated with an event, and in the policy language this becomes part of the constraint field. It is a predicate on event attributes (only) which is evaluated when the event occurs. It is used to hide or mask the occurrence of that event and therefore provides filtering capabilities. For example, on i:invalid login when i.used id == 123 where i is an event variable for event class invalid login. A dot notation is used to access its attributes. Complex events are not available in the policy language, but are available to the monitoring service. Two or more primitive and or composite events can be combined using various event composition operators to specify composite events in an hierarchical manner. Each composite event may also have an optional guard. Event composition operators include disjunction and conjunction of events, and others, including: e1 –> e2 /* occurs when e2 ’s time stamp is greater than or equal to that of e1 */ e1 n /* specifies the nth occurrence of an event */ notduring e1 ; e2 ; e3 /* occurs when e3 follows e1 with no intervening e2 */ For example,
[]
(
)
6
(t:temperature increased when t.tval > 120) –> pressure increased /* temperature increase greater than 120 followed by pressure increase */ invalid login[3] /* three invalid logins */ Event-based conditions, or triggers, are useful for instigating obligations on automated managers. A trigger defined as a predicate on the state could also be used for this purpose (e.g. object.size > 20). Such predicates are currently only placed in the constraint field (see Section 3.5) and are not allowed in the activity section. In this context the change in state is relevant (i.e. this may lead to an event being triggered), rather than the actual state itself at any one time. For an authorisation policy a condition would be evaluated as requests were made to a reference monitor enforcing the policy, but this is simply equivalent to a constraint, and hence event-based conditions are not part of authorisation policies. Event and state information (object attributes) and actions (methods) referenced in a policy may be supplied by a variety of objects through their management interfaces. They include some general system objects available to all policies (e.g. system clock supplying time information), subjects, targets, and possibly other policy objects subject to further research (e.g. a certain policy must be applied conditional upon another policy not being enforced (i.e. present within the policy system), hence giving the second policy a higher priority than the other). In a high-level policy both the condition and action parts may be expressed in abstract forms as comments, e.g. “General Manager O on /* poor profit */ f /* implement measures to increase profit */ g ;”.
+
3.5 Constraint The constraint field is for specifying general constraints on the applicability of a policy. Typical constraints include limiting the application of a policy to a particular time period, or applying it from a particular date. A constraint takes the form of a predicate which may refer to event attributes from the condition part, system state, subject and target attributes, and parameters of actions. It may also be desirable to allow limited method invocation within a constraint, with methods from the subject and possibly the target and system. These would be “limited” in the sense that they should perform no action (or effect no state change) since this would belong in the activity, but could perform simple queries and data conversions. For example, a printer manager might maintain a current job queue, and a policy might need to know the user associated with a given job number, which could be provided by querying the printer manger with a method invocation. The constraint field is also useful for specifying that a policy refers to a fixed number of subjects (or targets) of a given domain scope expression, rather than the default which is all of them. For example, given a domain of system managers, one might want an obligation policy specifying that one of the managers perform some action, such as perform a backup or create a new account. Using the label sm for the . subject domain, this would appear in the constraint as sm
# == 1
7
4 Example Policies Policy eg1 below is a simple example of an authorisation policy. It illustrates the use of a domain scope expression (in this case the union of two domains) to grant read and write access to a set of users. The system administrators and security administrators domains are examples of roles, where the objects occupying these domains assume the policies specified about them. The domains are referred to using hierarchical paths, which in general will need to be used, but will not be for further examples here for the sake of brevity. Notice too that the action is a list of two action, which means permitted to read and permitted to write in this case.
+
eg1 A /ic/computing/system administrators + /ic/computing/security administrators read(); write() g /ic/computing/password files ;
f
The printer manager policies below (pm) show a small example of hierarchical policies. The first two policies are high-level abstract policies specified using comments, pm2 being a refinement of pm1 in that the system administrator has decided to apportion his provision obligation to the printer manager. The other three policies are further refinements that are implementable policies.
+
pm1 O /org/roles/system administrator f /* provide and maintain a printing service for users */
+
pm2 O printer manager f /* provide printing service for users */
+
g;
g;
pm3.1 O on pf:print failed printer manager f mail(pf.user, pf.message) g mail server ;
+
pm3.2 A users ? temporary users f submit print job() g printer manager ;
+
pm3.3 A u:users f remove job(j) g pm:printer manager when pm.getuser(j) == u ;
Assuming there that when a print job fails an event print failed is recognised by the monitoring service, pm3.1 says that the printer manager will then use the mail server to send mail to the user who submitted the failed job. Using the label pf, the user and failure message are extracted from the event. Policy pm3.2 permits all users except temporary ones to submit jobs to the printer manager. A constraint is used in pm3.3 to only authorise the respective owners of jobs to remove them from the print queue. Notice here that a method of the target (printer manager) is used to convert the known job number into a user, which is then checked with the user attempting to perform the action. A further example below allows a user to read personnel records which have a suitably small grade. Furthermore, this access is only allowed during working hours.
+
eg2 A Ruth f read() g pr:personnel records when pr.grade < 10 && [8:00] < local time
