Ambient authority

From Erights

(Difference between revisions)
Jump to: navigation, search
(Correction suggested to me by Ben Laurie)
Line 1: Line 1:
-
The correct interpretation of this page relies on proper interpretation of words: [[subject, object, operation and permission]].
+
If a [[subject]] can [[operation on object|operate]] on all [[object]]s of a given type, we say that it has '''ambient authority'''.
-
== Definition ==
+
Several access control models were invented and implemented to enable restriction of ambient authority (to access all objects of a given type) of subjects. Many of them are:
 +
* either weak (we cannot follow the [[POLA|principle of least authority]])
 +
* or convoluted (it is hard to learn how to work with this model and be sure about achieved security level).
 +
Things become more "interesting" if we have to consider different security policies enforced via different alternative security mechanisms for the same type of objects and for different type of objects and the relevant transitivity relationship.
-
IF a subject requests an action, typically by naming an object and an operation on that object, and the action is allowed because the subject has a permission that would allow the action, THEN we say that the subject has '''ambient authority'''.
+
= Examples of ambient authority =
-
== Notes concerning the definition ==
+
If we consider files owned by some UNIX user as [[object]]s and UNIX processes as [[subject]]s then all processes have ''ambient authority'' to manipulate all those files.
-
Instead of "naming" an object, capability community often uses the term "designation" of an object.
+
If we consider TCP ports 1024--65535 as [[object]]s and and UNIX processes as [[subject]]s then all processes have ''ambient authority'' to listen to any ports.
-
Whether we can say that some chosen subject has '''ambient authority''' or not is solely determined by the fact HOW are operations allowed or denied. It is independent from the fact WHAT PERMISSIONS a given subject actually has. This matters in case of a term [[excess authority]].
+
If we consider all executable programs owned by some UNIX user as [[object]]s and all UNIX processes as run by the same user as [[subject]]s then all these processes have ''ambient authority'' to run any of those programs.
-
The difference between [[ambient authority system]] and the [[designated authority system]] is that:
+
If we consider all functions defined in some C program as [[subject]]s and all functions in the same C program as [[object]]s then any function has ''ambient authority'' to call any other function (in C we can cast any integer to a function pointer and perform the call operation with this forged reference to a function).
-
* in the first case subjects, when they request some operation with some object, '''do not have to''' specify the permission that allows given operation with given object;
+
-
* in the latter case subject, when they request some operation with some object, '''have to''' specify the permission this request with designated the permission that allows given operation with given object.
+
-
== See also ==
+
If we consider all functions defined in some C program as [[subject]]s and all regions of the address space of the relevant process as [[object]]s then all these functions have ''ambient authority'' to read from or write to any such memory region.
-
 
+
-
* [[Excess authority]]
+
-
* [[Ambient authority system]]
+
-
 
+
-
== Examples of ambient authority ==
+
-
 
+
-
All UNIX processes run with some effective user id have ambient authority to manipulate all files accessible by that user id.
+
-
 
+
-
All UNIX processes have ''ambient authority'' to listen to TCP or UDP ports 1024--65535.
+
-
 
+
-
All UNIX processes have ''ambient authority'' to send any signal to any other UNIX process.
+
-
 
+
-
== Acknowledgement ==
+
-
 
+
-
The term ''ambient authority'' was coined by Dean Tribble and Mark S. Miller.
+

Revision as of 09:20, 11 June 2009

If a subject can operate on all objects of a given type, we say that it has ambient authority.

Several access control models were invented and implemented to enable restriction of ambient authority (to access all objects of a given type) of subjects. Many of them are:

  • either weak (we cannot follow the principle of least authority)
  • or convoluted (it is hard to learn how to work with this model and be sure about achieved security level).

Things become more "interesting" if we have to consider different security policies enforced via different alternative security mechanisms for the same type of objects and for different type of objects and the relevant transitivity relationship.

Examples of ambient authority

If we consider files owned by some UNIX user as objects and UNIX processes as subjects then all processes have ambient authority to manipulate all those files.

If we consider TCP ports 1024--65535 as objects and and UNIX processes as subjects then all processes have ambient authority to listen to any ports.

If we consider all executable programs owned by some UNIX user as objects and all UNIX processes as run by the same user as subjects then all these processes have ambient authority to run any of those programs.

If we consider all functions defined in some C program as subjects and all functions in the same C program as objects then any function has ambient authority to call any other function (in C we can cast any integer to a function pointer and perform the call operation with this forged reference to a function).

If we consider all functions defined in some C program as subjects and all regions of the address space of the relevant process as objects then all these functions have ambient authority to read from or write to any such memory region.

Retrieved from "http://wiki.erights.org/wiki/Ambient_authority"
Personal tools
more tools