Jump to content

Separation of mechanism and policy: Difference between revisions

From Wikipedia, the free encyclopedia
Browse history interactively
← Previous editNext edit →
Content deleted Content added
VisualWikitext
m Removed category "Computer science"; Quick-adding category "Operating system technology" (using HotCat)
typo, style
Line 1: Line 1:
{{Cleanup|date=June 2008}}
{{Cleanup|date=June 2008}}
The '''Separation of [[Mechanism (technology)|mechanism]]<ref>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)</ref> and [[policy]]''' is a fundamental design principle in the field of [[Computer science]]. It states that '''mechanisms''' (those parts of a system
The '''separation of mechanism and policy'''<ref>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)</ref> 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.

implementation that control
⚫
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
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 (authentication and authorization)
'''mechanisms''', 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
problems (e.g. CPU scheduling, memory allocation, Quality of Service), and the general
question of good object abstraction.
question of good object abstraction.


[[Per Brinch Hansen]] presented [[Cogency|cogent]] arguments in favor of separation of mechanism and policy.<ref name="Wulf74">Wulf 74 pp.337-345</ref><ref name="Hansen70">Brinch Hansen 70 pp.238-241</ref>
[[Per Brinch Hansen]] presented arguments in favor of separation of mechanism and policy.<ref name="Wulf74">Wulf 74 pp.337-345</ref><ref name="Hansen70">Brinch Hansen 70 pp.238-241</ref>


Artsy, in a 1987 paper, discussed an approach for an operating system design having an "extreme separation of mechanism and policy".<ref>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.)</ref><ref>Artsy, Yeshayahu ''et al'', 1987</ref>
Artsy, in a 1987 paper, discussed an approach for an operating system design having an "extreme separation of mechanism and policy".<ref>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.)</ref><ref>Artsy, Yeshayahu ''et al'', 1987</ref>
Line 18: Line 14:
==Rationale and Implications==
==Rationale and Implications==


The '''separation of mechanism and policy''' is the fundamental approach of a [[microkernel|micro]] [[Kernel (computer science)|kernel]] that distinguishes it from a [[Monolithic kernel|monolithic]] one. In a microkernel the majority of operating system services are provided by user-level server processes.<ref>[[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. </ref> 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'''.<ref>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.</ref>
The separation of mechanism and policy is the fundamental approach of a [[microkernel]] that distinguishes it from a [[Monolithic kernel|monolithic]] one. In a microkernel the majority of operating system services are provided by user-level server processes.<ref>[[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. </ref> It is considered important{{by whom}} for an [[operating system]] to have the flexibility of providing adequate mechanisms to support the broadest possible spectrum of real-world security policies.<ref>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.</ref>


It is almost impossible to envision all of the different ways in which a system might be used
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''
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.
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
Decoupling the mechanism implementations from the policy specifications makes it
possible for different applications to use the same '''mechanism''' implementations
possible for different applications to use the same mechanism implementations
with different '''policies'''. This means that those '''mechanisms''' are likely to better
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.
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,
There is always a cost, and a risk associated with changes to any system implementation.
⚫
the costs and risks of such policy changes can be greatly reduced. This could be accomplished merely
⚫
If it is possible to enable new '''policies''' without changing the implementing '''mechanisms''',
by 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 create some non-code means for specifying policies. For instance, policies (e.g. UNIX user/group/other read/write/execute file protections) might be paametrized. Alternatively the implementing mechanisms could be designed to include an interpreter for a new policy specification language. These are usually accompanied by a deferred binding mechanism (e.g. configuration files, or APIs) that permits policy specifications to be added to the system after it has been delivered to the customer.
⚫
the costs and risks of such '''policy ''' changes can be greatly reduced.
This could be accomplished merely
by 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 create
some non-code means for specifying '''policies'''. We might, for instance, parametrize our
'''policies''' (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. configuration
files, or APIs) that permits '''policy''' specifications to be added to the system
after it has been delivered to the customer.


An 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.
A good every-day 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. This architecture achieves a high degree of
'''mechanism/policy separation'''


==Notes==
==Notes==

Revision as of 07:10, 29 January 2009

The separation of mechanism and policy[1] 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.[2][3]

Artsy, in a 1987 paper, discussed an approach for an operating system design having an "extreme separation of mechanism and policy".[4][5]

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

Rationale and Implications

The separation of mechanism and policy is the fundamental approach of a microkernel that distinguishes it from a monolithic one. In a microkernel the majority of operating system services are provided by user-level server processes.[7] It is considered important[by whom?] for an operating system to have the flexibility of providing adequate mechanisms to support the broadest possible spectrum of real-world security policies.[8]

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. This could be accomplished merely by 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 create some non-code means for specifying policies. For instance, policies (e.g. UNIX user/group/other read/write/execute file protections) might be paametrized. Alternatively the implementing mechanisms could be designed to include an interpreter for a new policy specification language. These are usually accompanied by a deferred binding mechanism (e.g. configuration files, or APIs) that permits policy specifications to be added to the system after it has been delivered to the customer.

An 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.

Notes

  1. ^ Butler W. Lampson and Howard E. Sturgis. Reflections on an Operating System Design [1] Communications of the ACM 19(5):251-265 (May 1976)
  2. ^ Wulf 74 pp.337-345
  3. ^ Brinch Hansen 70 pp.238-241
  4. ^ Miller, M. S., & Drexler, K. E. (1988). Markets and computation: Agoric open systems. In Huberman (1988), pp. 133{176. (Huberman, B. A. (Ed.). (1988). The Ecology of Computation. North-Holland.)
  5. ^ Artsy, Yeshayahu et al, 1987
  6. ^ Chervenak 2000 p.2
  7. ^ 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.
  8. ^ R. Spencer, S. Smalley, P. Loscocco, M. Hibler, D. Andersen, and J. Lepreau The Flask Security Architecture: System Support for Diverse Security Policies In Proceedings of the Eighth USENIX Security Symposium, pages 123–139, Aug. 1999.

References

  • Per Brinch Hansen (2001). "The evolution of operating systems" (pdf). Retrieved 2006-10-24. {{cite journal}}: Cite journal requires |journal= (help) included in book: Per Brinch Hansen (ed.). "1". Classic operating systems: from batch processing to distributed systems. New York,: Springer-Verlag. pp. 1–36. ISBN 0-387-95113-X. {{cite book}}: External link in |chapterurl= (help); Unknown parameter |chapterurl= ignored (|chapter-url= suggested) (help); Unknown parameter |origdate= ignored (|orig-date= suggested) (help)CS1 maint: extra punctuation (link) (p.18)
  • Wulf, W. (1974). "HYDRA: the kernel of a multiprocessor operating system". Communications of the ACM. 17 (6): 337–345. doi:10.1145/355616.364017. ISSN 0001-0782. {{cite journal}}: Unknown parameter |coauthors= ignored (|author= suggested) (help); Unknown parameter |month= ignored (help) (pp.337-345)
  • Hansen, Per Brinch (1970). "The nucleus of a Multiprogramming System". Communications of the ACM. 13 (4): 238–241. doi:10.1145/362258.362278. ISSN 0001-0782. {{cite journal}}: Unknown parameter |month= ignored (help) (pp.238-241)
  • Levin, R. (1975). "Policy/mechanism separation in Hydra". ACM Symposium on Operating Systems Principles / Proceedings of the fifth ACM symposium on Operating systems principles: 132–140. doi:10.1145/800213.806531. {{cite journal}}: Unknown parameter |coauthors= ignored (|author= suggested) (help)
  • Chervenak et al The data grid Journal of Network and Computer Applications, Volume 23, Issue 3, July 2000, Pages 187-200
  • Artsy, Yeshayahu, and Livny, Miron, An Approach to the Design of Fully Open Computing Systems (University of Wisconsin / Madison, March 1987) Computer Sciences Technical Report #689.
  • Wulf, W. (1974). "HYDRA: the kernel of a multiprocessor operating system". Communications of the ACM. 17 (6): 337–345. doi:10.1145/355616.364017. ISSN 0001-0782. {{cite journal}}: Unknown parameter |coauthors= ignored (|author= suggested) (help); Unknown parameter |month= ignored (help)

See also

Retrieved from "https://en.wikipedia.org/enwiki/w/index.php?title=Separation_of_mechanism_and_policy&oldid=267147013"