Separation of mechanism and policy
Encyclopedia
The separation of mechanism and policy is a design principle in computer science
. It states that mechanisms (those parts of a system implementation that control the authorization of operations and the allocation of resources) should not dictate (or overly restrict) the policies according to which decisions are made about which operations to authorize, and which resources to allocate.
This is most commonly discussed in the context of security mechanisms (authentication and authorization), but is actually applicable to a much wider range of resource allocation
problems (e.g. CPU scheduling, memory allocation, Quality of Service), and the general
question of good object abstraction.
Per Brinch Hansen
presented arguments in favor of separation of mechanism and policy.
Artsy, in a 1987 paper, discussed an approach for an operating system design having an "extreme separation of mechanism and policy".
In a 2000 article, Chervenak et al. described the principles of mechanism neutrality and policy neutrality.
that distinguishes it from a monolithic
one. In a microkernel the majority of operating system services are provided by user-level server processes. It is considered important for an operating system
to have the flexibility of providing adequate mechanisms to support the broadest possible spectrum of real-world security policies.
It is almost impossible to envision all of the different ways in which a system might be used
by different types of users over the life of the product. This means that any hard-coded
policies are likely to be inadequate or inappropriate for some (or perhaps even most) users.
Decoupling the mechanism implementations from the policy specifications makes it
possible for different applications to use the same mechanism implementations
with different policies. This means that those mechanisms are likely to better
meet the needs of a wider range of users, for a longer period of time.
If it is possible to enable new policies without changing the implementing mechanisms,
the costs and risks of such policy changes can be greatly reduced. In the first instance, this could be accomplished merely
by segregating mechanisms and their policies into distinct modules: by replacing the module which dictates a policy (e.g. CPU scheduling policy) without changing the module which executes this policy (e.g. the scheduling mechanism), we can change the behaviour of the system. Further, in cases where a wide or variable range of policies are anticipated depending on applications' needs, it makes sense to create some non-code means for specifying policies, i.e. policies are not hardcoded into executable code but can be specified as an independent description. For instance, file protection policies (e.g. Unix's user/group/other read/write/execute ) might be parametrized. Alternatively an implementing mechanism could be designed to include an interpreter for a new policy specification language. In both cases, the systems are usually accompanied by a deferred binding mechanism (e.g. configuration files, or APIs) that permits policy specifications to be incorporated to the system or replaced by another after it has been delivered to the customer.
An everyday example of mechanism/policy separation is the use of card-keys to gain access to locked doors. The mechanisms (magnetic card readers, remote controlled locks, connections to a security server) do not impose any limitations on entrance policy (which people should be allowed to enter which doors, at which times). These decisions are made by a centralized security server, which (in turn) probably makes its decisions by consulting a database of room access rules. Specific authorization decisions can be changed by updating a room access database. If the rule schema of that database proved too limiting, the entire security server could be replaced while leaving the fundamental mechanisms (readers, locks, and connections) unchanged.
Computer science
Computer science or computing science is the study of the theoretical foundations of information and computation and of practical techniques for their implementation and application in computer systems...
. It states that mechanisms (those parts of a system implementation that control the authorization of operations and the allocation of resources) should not dictate (or overly restrict) the policies according to which decisions are made about which operations to authorize, and which resources to allocate.
This is most commonly discussed in the context of security mechanisms (authentication and authorization), but is actually applicable to a much wider range of resource allocation
problems (e.g. CPU scheduling, memory allocation, Quality of Service), and the general
question of good object abstraction.
Per Brinch Hansen
Per Brinch Hansen
Per Brinch Hansen was a Danish-American computer scientist known for concurrent programming theory.-Biography:He was born in Frederiksberg, in Copenhagen, Denmark....
presented arguments in favor of separation of mechanism and policy.
Artsy, in a 1987 paper, discussed an approach for an operating system design having an "extreme separation of mechanism and policy".
In a 2000 article, Chervenak et al. described the principles of mechanism neutrality and policy neutrality.
Rationale and Implications
The separation of mechanism and policy is the fundamental approach of a microkernelMicrokernel
In computer science, a microkernel is the near-minimum amount of software that can provide the mechanisms needed to implement an operating system . These mechanisms include low-level address space management, thread management, and inter-process communication...
that distinguishes it from a monolithic
Monolithic kernel
A monolithic kernel is an operating system architecture where the entire operating system is working in the kernel space and alone as supervisor mode...
one. In a microkernel the majority of operating system services are provided by user-level server processes. It is considered important for an operating system
Operating system
An operating system is a set of programs that manage computer hardware resources and provide common services for application software. The operating system is the most important type of system software in a computer system...
to have the flexibility of providing adequate mechanisms to support the broadest possible spectrum of real-world security policies.
It is almost impossible to envision all of the different ways in which a system might be used
by different types of users over the life of the product. This means that any hard-coded
policies are likely to be inadequate or inappropriate for some (or perhaps even most) users.
Decoupling the mechanism implementations from the policy specifications makes it
possible for different applications to use the same mechanism implementations
with different policies. This means that those mechanisms are likely to better
meet the needs of a wider range of users, for a longer period of time.
If it is possible to enable new policies without changing the implementing mechanisms,
the costs and risks of such policy changes can be greatly reduced. In the first instance, this could be accomplished merely
by segregating mechanisms and their policies into distinct modules: by replacing the module which dictates a policy (e.g. CPU scheduling policy) without changing the module which executes this policy (e.g. the scheduling mechanism), we can change the behaviour of the system. Further, in cases where a wide or variable range of policies are anticipated depending on applications' needs, it makes sense to create some non-code means for specifying policies, i.e. policies are not hardcoded into executable code but can be specified as an independent description. For instance, file protection policies (e.g. Unix's user/group/other read/write/execute ) might be parametrized. Alternatively an implementing mechanism could be designed to include an interpreter for a new policy specification language. In both cases, the systems are usually accompanied by a deferred binding mechanism (e.g. configuration files, or APIs) that permits policy specifications to be incorporated to the system or replaced by another after it has been delivered to the customer.
An everyday example of mechanism/policy separation is the use of card-keys to gain access to locked doors. The mechanisms (magnetic card readers, remote controlled locks, connections to a security server) do not impose any limitations on entrance policy (which people should be allowed to enter which doors, at which times). These decisions are made by a centralized security server, which (in turn) probably makes its decisions by consulting a database of room access rules. Specific authorization decisions can be changed by updating a room access database. If the rule schema of that database proved too limiting, the entire security server could be replaced while leaving the fundamental mechanisms (readers, locks, and connections) unchanged.
External links
- An operating system Vade Mecum [ftp://ftp.cs.uky.edu/cs/manuscripts/vade.mecum.2.pdf]
- Mechanism and policy for HTC