Experience with a crudely delegated user interface to our internally developed configuration management system convinced us that delegated access to configuration systems was worth pursuing properly. This paper outlines our approach to authorising access both to individual aspects of configurations and to collections of configurations. We advocate the use of authorisation of some kind on configuration changes and we believe that the system of authorising primitive manipulations of a configuration representation outlined herein could be accommodated by a number of existing configuration systems. The authorisation system described is still experimental and we regret that real world experience of the system in use with end users is not yet available.
There are a number of configuration management systems for computers [12, 13, 15, 6, 7, 14]. Of those, all those known to us assume that use of the configuration management system will be restricted to those people who would have been system administrators on the managed collection of computers in the absence of the configuration management system. One can usually use file-system permissions or other mechanisms (inherited ACLs operating in a similar fashion to file-system permissions in Active Directory [10] or database access controls in SMS) to allow or deny access to the configuration representations of computers, but those mechanisms are difficult to use in a structured manner, do not allow delegated control of sub-parts of machine configuration information and, with the exception of Active Directory's ACLs, are not at all designed with configuration delegation in mind.
There are a number of reasons it is desirable to delegate configuration management as much as possible:
Of course, there are also extra complications when many people can edit configuration information.
Of the systems mentioned above, only Active Directory with its LDAP based hierarchy explicitly allows for delegation and sub-delegation of computer configuration on collections of computers. Active Directory's tree structure suffers from the deficiencies inherent in single inheritance trees outlined later, however. These have a negative impact on the way that configuration information may be organised and composed, and on the way that configuration tasks may be delegated. None of those systems allow delegation of access to aspects [2, 3] of the configuration - if one has access to the object representing the computer, one can change anything the configuration management system is capable of controlling.
In this paper, a method for organising and delegating access to configuration information is discussed. These ideas have been implemented in an (as yet) experimental extension to our existing configuration management system, ``Machination'' [11].
First, strategic goals and desired features and properties of the system are discussed. The paper then covers two main authorisation topics: how to represent and manipulate configuration information such that control over aspects can be authorised; and how to organise configuration information when dealing with many configuring entities and configurable objects.
With the above justification in mind, the following high level goals were set and used as guidelines to extend our existing configuration management system.
At a more detailed level, the following requirements relevant to authorisation were set for the system:
The ability to authorise access to configuration aspects individually requirement, set out above, requires the system to authorise access to individual configuration aspects. These aspects are elements of configuration information which are logically connected in some way - packages, web server configuration, network settings or the like. To facilitate this, a representation for configuration information was sought with the following properties:
In our case the representation chosen was based on XML with the following restrictions:
/tag/arrayTag[@id='id1']/tag/...This is important for the configuration manipulating instructions described in the next section. In fact, since the id attribute is the only one required to address elements, in many cases xpaths are abbreviated to the form:
/tag/arrayTag[id1]/tag/...Rule 3 is stated for completeness, though it is considered unlikely that anyone would wish to use the id attribute for anything else.
Assuming a mechanism exists for translating XML to real configuration (and it does exist) the problem of configuration management has been reduced to producing and distributing valid XML for that mechanism. Quite a number of configuration management systems take a similar approach - for example LCFG distributes configuration information via an XML representation [4], while bcfg2 configurations are specified in XML [5]. The rules described above restrict our XML representation to be simpler than would be allowed in plain XML, and allow it to be manipulated using a set of primitive operations (as described in the next section) which require the unique xpaths described above to address elements in the representation. It is those primitive operations to which authorisation rules are applied.
XML representations conforming to the rules described above may be manipulated using the following primitives:
In Machination these primitives are called configuration instructions and are collected together in a hierarchical structure as described later.
The instruction set described above can be used to make demands about some configuration representation. They are very general - one can construct fairly arbitrary XML with them - and that they are reasonably small in number. It is to these primitives, or configuration instructions, that authorisation rules are applied.
Authorisation instructions are held in a database, and a typical instruction might be represented as something like that shown in Listing 1, which says that user joe [Note 1] should be allowed to add sub-elements to /profile/ worker[packageman-1] as long as the sub-element's tag is ``package'' and its id matches the name of one of the elements of the set ``unrestricted packages.''
is_allow: 1
entities: joe
operation: add_elt
xml_path: /profile/worker[packageman-1]
pattern: <pattern>
<constraint on="tag" type="string">package</constraint>
<constraint on="id" type="set" set_id="unrestricted packages"/>
</pattern>
The schema for any eventual representation should be designed such that related pieces of configuration are bundled together in the representation. It is these related configuration pieces that form configuration aspects. An authorisation instruction relates to, and thus controls access to, an aspect if its xml_path attribute contains the XML path of the aspect.
The optional pattern clause allows the instruction to be more selective, subject to the content of the potential change. Tags and ids may be constrained for add_elt and del_elt, attribute names and values for set_att and so on. Current constraints allowed include string-wise equality, regular expressions, one of a provided list of strings, equal to the name (or other specified) attribute of one of the members of a set and their appropriate negatives.
Authorisation instructions control the ability of configuration instructions (primitives acting on XML) to access individual aspects of a configuration. The other promised topic for authorisation was authorising access to the structure which organises configuration information for lots of objects, which is introduced next.
When configuring lots of objects, it is necessary to collect them together in some way. Strategies for this include database sets with no inheritance relationship (e.g., collections in Microsoft SMS), tree inheritance (e.g., OU tree in Microsoft Active Directory) and inverted tree inheritance (e.g., #include in LCFG, groups in Bcfg). SMS's unstructured sets lack an inheritance mechanism. The difference between the other two systems is similar to the difference between the is-a and has-a relationships in object oriented programming, though the distinction between the two is less clear in configuration management since `inheritance' here is usually synonymous with accruing properties and values, and has no meaning in terms of method inheritance and method over-rides.
We now consider the implications of authorising actions on representations for these two types of inheritance.
This kind of structure forms a tree of categories with the whole organisation at the root. The categories can be thought of as containers (as they are in Active Directory), containing configurable objects and other containers. Configuration instructions are attached to containers and apply to all configurable objects in that container or any of its sub containers.
Machination uses this style of inheritance (including multiple inheritance, as described below). Aspect authorisation instructions in Machination are attached to containers in the same way as configuration instructions, as shown in Figure 1. The authorisation instructions determine which configuration instructions are allowed to apply when the instructions are compiled into a representation, and are inherited from the root down the tree to the container being evaluated. A computer in the ``finance'' container in the tree shown would accrue instructions as shown in Table 1. Notice that the instruction to add package ``fin'' attached to the finance container is allowed because of an authorisation instruction attached to the ACME container.
| Source | Instruction | Allowed? | Reason |
| ACME | add package ``pkg1'' | allowed | ACME allow packages |
| set screensaver text ``asleep'' | denied | ACME deny all | |
| finance | add package ``fin'' | allowed | ACME allow packages |
| set screensaver text ``Finance: asleep'' | allowed | finance allow screensaver |
With this kind of structure, each configurable object has an associated tree rooted at that object. Each object can include or subscribe to collections of configuration instructions, and each such collection can include other collections.
For this style of inheritance aspect authorisation instructions could be included with the collections of configuration instructions as shown in Figure 2. Such authorisation instructions would determine which configuration instructions are allowed in the collection, which could be evaluated either at attachment time or at representation compile time.
The full list and order of authorisation instructions (and thus the results of the authorisation step) is order dependent, and cannot be determined from Figure 2 without further ordering information. This is explored in more detail later.
Either inheritance mechanism described above can support multiple inheritance. In is-a trees this is achieved by allowing objects to appear in more than one container and in has-a inverted trees by allowing more than one include or subscription. It was decided that Machination should support multiple inheritance to avoid the following two problems:
Supporting multiple inheritance immediately leads to the possibility of conflicts. Considering again the trees in Figures 1 and 2, if a computer exists in both the finance and marketing containers, or includes both finance and marketing files, it will have instructions both to add and remove the package ``fin''. Clearly these conflict. These configuration instructions must be merged in such a way that such conflicts are resolved.
The usual way this is resolved is to order the instructions. For is-a trees this means choosing a fixed evaluation order for all sibling containers. For example, the evaluation order of the finance and marketing containers in Figure 1 would need to be specified. For has-a inverted trees this means the inclusion order must be specified. In Figure 2, this would mean specifying the order in which the finance and marketing files were included, as well as whether the computer 1 instructions come before or after those inclusions and whether the ACME file is included before or after the instructions in each of the marketing and finance files.
So far the discussion has proceeded as if the hierarchy (is-a or has-a) is fixed, and the results are being computed based on placement of configurable objects and instructions within that hierarchy. The shape of the tree structure (includes or containers), the position of configuration and authorisation instructions, the position of configurable objects and the ordering of all of these are important both to the final configurations and to the nature of delegated portions. Changes to all of these need to be authorised.
It is beyond the scope of this paper to discuss authorisation of actions on the chosen hierarchy itself in any depth; however such operations fall more within the scope of the usual access control mechanisms to filesystem or directory objects. Machination's approach is to treat the hierarchy as a configurable object with a representation as defined earlier and to authorise modifications of that representation as described. Thus everything is unified under one authorisation system.
Both inheritance mechanisms described above have their advantages and disadvantages. The choice in Machination came from a trade-off between configuration flexibility and clarity for delegated contributors.
The has-a model is more flexible. The fact that instructions can be re-ordered on a configurable object by configurable object basis means that conflicting inclusions and instructions can be re-ordered to suit. However, such re-ordering of inclusions changes what delegated contributors are allowed to change, due to re-ordering of the associated authorisation information. This makes it less clear to contributors what they are and are not allowed to do. This and the possibility of interleaving includes, configuration instructions and authorisation instructions also make it more difficult to present such information to contributors in a graphical user interface.
The multiple inheriting is-a structure was chosen as the basis for the Machination hierarchy, in large part due to the relative ease of presenting compartmentalised views to delegated contributors.
The following features of the Machination hierarchy are more specific design choices in Machination and less relevant to the discussion on how to apply authorisation to general configuration systems. They are nonetheless important design choices with respect to the way that delegated portions of the Machination hierarchy interact.
As mentioned earlier, choosing is-a style inheritance leaves Machination with a less flexible structure. We gain some flexibility back by introducing the concept of merge policies which may be attached to containers, and are applied when configuration instructions from multiple sibling containers are merged.
These specify the precedence of instructions between sibling containers depending on the contents of the instruction. Currently, the only information one can use is the element path to be altered, though this may be expanded to include details such as the attribute or text value being set. As an example, one could specify that the tree under the by network merge point should have precedence over the firewall area of a Machination Windows profile by attaching a merge policy of the form:
for xml_path /profile/worker[firewall-1] \
local wins
where, similarly to the authorisation instruction shown earlier, the
policy is stored as discrete data values in the hierarchy, rather than
as a written command.
If there is a clash in merge policies (for example if two sibling containers' policies both claim precedence over one path in the profile) the siblings order in the parent is used to resolve precedence, just as if the policy statement did not exist.
Combining merge policies with authorisation instructions can be useful when delegating expertise specific configuration tasks. For example, suppose that an organisation has a networking expert. This expert should make sure that firewall rules are in place on each client appropriate for the client's network and status. We can set up a merge point called by network and delegate full control of the substructure to the expert (who will have a good idea of how to structure it for best results). The merge policy should be set to give precedence to that container for firewall rules, but to cede precedence for everything else and the authorisation instructions should allow configuration of only the firewall section of the profile. The expert can now organise computers into containers as required, perhaps resulting in a tree like that shown in Figure 5.
Multiple inheritance can be a dangerous thing. As a configurable object inherits configuration information from more paths it is more likely that conflicts will result and it becomes more difficult to follow and visualise a configuration back to its sources. Some temperance is required. As an aide to this (or perhaps an enforcement of it), Machination only allows configurable objects to be placed in two containers if they are separated by a merge point. For example, in Figure 5, a computer could be placed in both the low risk and subnet A containers, but not in both the low risk and high risk containers.
Merge points essentially break the multiply inheriting tree up into multiple singly inheriting trees, which are much simpler. Merge points should be inserted wherever one or both of the limitations of singly inheriting trees appears (i.e., different division criteria or multiple categories are required). The idea is to use as many merge points as one needs, but as few as one can get away with.
We have the beginnings of a system we hope will allow us to reduce our configuration workload at the same time as making our users and our managers happy. Our hope is based on experience with a useful but deficient system and underpinned by some new authorisation features. We are confident we will be able to delegate access to configuration aspects to desktop and laptop systems' end users, as well as more sophisticated forms of delegation with respect to collections of computers.
We believe that the authorisation work presented here, particularly the work on authorising access to individual configuration aspects, is transportable to other configuration systems and would be pleased to see others consider it. To this end, the Machination project is being open sourced, and code, or a link to it, should be available at the Machination project page [11] by the time this paper is published.
There is much work left to do, both on Machination and investigating more general consequences of authorising configurations. Some we have identified in the following.
Colin Higgs graduated from the University of Edinburgh with an Honours degree in Mathematical Physics. After a few years working as a physicist, Colin became the sole system administrator for the department of Chemical Engineering back at the University of Edniburgh. Several mergers and re-organisations later, he is now part of a larger team for the School of Engineering and Electronics, where he at least tries to work toward the ``Bahamas'' model of computing support.