Separation of mechanism and policy

The Separation of mechanism [Butler W. Lampson and Howard E. Sturgis. " [http://research.microsoft.com/Lampson/15-ReflectionsOnOS/Acrobat.pdf Reflections on an Operating System Design] " [http://portal.acm.org/citation.cfm?id=360051.360074] Communications of the ACM 19(5):251-265 (May 1976)] and policy is a fundamental design principle in the field of Computer science. It states that mechanisms (those parts of a systemimplementation that control the authorization of operations and the allocation of resources) should not dictate (or overlyrestrict) the policies according to which decisions are made about which operations toauthorize, and which resources to allocate.This is most commonly discussed in the context of security (authentication and authorization)mechanisms, but is actually applicable to a much wider range of resource allocationproblems (e.g. CPU scheduling, memory allocation, Quality of Service), and the general question of good object abstraction.

Per Brinch Hansen presented cogent arguments in favor of separation of mechanism and policy.Wulf 74 pp.337-345] Brinch Hansen 70 pp.238-241]

Artsy, in a 1987 paper, discussed an approach for an operating system design having an "extreme separation of mechanism and policy". [Miller, M. S., & Drexler, K. E. (1988). " [http://www.agorics.com/Library/agoricpapers/aos/aos.4.html Markets and computation: Agoric open systems] ". In Huberman (1988), pp. 133{176. (Huberman, B. A. (Ed.). (1988). The Ecology of Computation. North-Holland.)] [Artsy, Yeshayahu "et al", 1987]

In a 2000 article, Chervenak et al described the principles of "mechanism neutrality" and "policy neutrality". [Chervenak 2000 p.2]

Rationale and Implications

The separation of mechanism and policy is the fundamental approach of a micro kernel that distinguishes it from a monolithic one. In a microkernel the majority of operating system services are provided by user-level server processes. [Raphael Finkel, Michael L. Scott, Artsy Y. and Chang, H. " [www.cs.rochester.edu/u/scott/papers/1989_IEEETSE_Charlotte.pdf Experience with Charlotte: simplicity and function in a distributed operating system] . IEEE Trans. Software Engng 15:676-685; 1989. Extended abstract presented at the IEEE Workshop on Design Principles for Experimental Distributed Systems, Purdue University; 1986. ] 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. [R. Spencer, S. Smalley, P. Loscocco, M. Hibler, D. Andersen, and J. Lepreau " [http://www.cs.utah.edu/flux/papers/flask-usenixsec99-abs.html The Flask Security Architecture: System Support for Diverse Security Policies] " In Proceedings of the Eighth USENIX Security Symposium, pages 123–139, Aug. 1999.]

It is almost impossible to envision all of the different ways in which a system might be usedby 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 itpossible for different applications to use the same mechanism implementations with different policies. This means that those mechanisms are likely to bettermeet the needs of a wider range of users, for a longer period of time.

There is always a cost, and a risk associated with changes to any system implementation.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. This could be accomplished merelyby segregating mechanisms and their policies into distinct modules, but in cases where a wide or variable range of policies are anticipated, it makes sense to createsome non-code means for specifying policies. We might, for instance, parametrize ourpolicies (e.g. UNIX user/group/other read/write/execute file protections). Alternatively we could design our implementing mechanisms to include an interpreter for a new policy specification language. These are usually accompanied by a deferred binding mechanism (e.g. configurationfiles, or APIs) that permits policy specifications to be added to the system after it has been delivered to the customer.

A good every-day example of Mechanism/Policy Separation is the use of card-keys togain 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 aremade by a centralized security server, which (in turn) probably makes its decisions by consultinga database of room access rules. Specific authorization decisions can be changed by updatinga room access database. If the rule schema of that database proved too limiting, the entiresecurity server could be replaced while leaving the fundamental mechanisms (readers, locks,and connections) unchanged. This architecture achieves a high degree of mechanism/policy separation

Notes

References

*cite paper
author =Per Brinch Hansen
title = The evolution of operating systems
date = 2001
url = http://brinch-hansen.net/papers/2001b.pdf
format = pdf
accessdate = 2006-10-24 included in book: cite book |editor=Per Brinch Hansen |title=Classic operating systems: from batch processing to distributed systems |origdate=2001 |url=http://portal.acm.org/citation.cfm?id=360596&dl=ACM&coll=&CFID=15151515&CFTOKEN=6184618 |publisher=Springer-Verlag |location= New York, |id=ISBN 0-387-95113-X |pages=1-36 |chapter=1 |chapterurl=http://brinch-hansen.net/papers/2001b.pdf (p.18)
*cite journal |last=Wulf |first=W. |coauthors=E. Cohen, W. Corwin, A. Jones, R. Levin, C. Pierson, F. Pollack |year=1974 |month=June |title=HYDRA: the kernel of a multiprocessor operating system |journal=Communications of the ACM |volume=17 |issue=6 |pages=337–345 |id=ISSN 0001-0782 |url=http://portal.acm.org/citation.cfm?id=364017&coll=portal&dl=ACM |doi=10.1145/355616.364017 (pp.337-345)
* (pp.238-241)
*cite journal |last=Levin |first=R. |coauthors=E. Cohen, W. Corwin, F. Pollack, W. Wulf |year=1975 |title=Policy/mechanism separation in Hydra |journal=ACM Symposium on Operating Systems Principles / Proceedings of the fifth ACM symposium on Operating systems principles |pages=132–140 |url=http://portal.acm.org/citation.cfm?id=806531&dl=ACM&coll=&CFID=15151515&CFTOKEN=6184618 |doi=10.1145/800213.806531
*Chervenak et al " [http://hpc.csie.thu.edu.tw/meeting/g93/g932910_Yao-Chun%20Chi/ycc_2005-11-04_The%20Data%20Grid_Towards%20an%20Architecture%20for%20the%20Distributed%20Management%20and%20Analysis%20of%20Large%20Scientific%20Datasets.pdf The data grid] " Journal of Network and Computer Applications, Volume 23, Issue 3, July 2000, Pages 187-200
*Artsy, Yeshayahu, and [http://pages.cs.wisc.edu/~miron/ Livny, Miron] , An Approach to the Design of Fully Open Computing Systems (University of Wisconsin / Madison, March 1987) Computer Sciences Technical Report #689.
*

ee also

*Separation of protection and security

External links

* [http://66.102.1.104/scholar?hl=it&lr=&q=cache:F89Ot76M9E0J:web.cefriel.it/~pomante/matvario/OSvademecum.pdf+%22An+Operating+Systems+Vade+Mecum%22 An operating system Vade Mecum] [ftp://ftp.cs.uky.edu/cs/manuscripts/vade.mecum.2.pdf]
* [http://www.cs.wisc.edu/condor/ Mechanism and policy for HTC]