Ambient authority

From Erights

(Difference between revisions)
Jump to: navigation, search
(Completely replace the definition)
(Correction suggested to me by Ben Laurie)
 
(13 intermediate revisions not shown)
Line 1: Line 1:
-
== Draft Definition ==
+
The correct interpretation of this page relies on proper interpretation of words: [[subject, object, operation and permission]].
-
A [[subject]] may have several different [[permission]]s. '''Ambient authority''' is authority that can be used without having to identify which specific permission is required. In an ambient authority system, when a subject requests an action (typically by naming an object and an operation on that object), the action is allowed if the subject has any permission for the action.
+
== Definition ==
-
In contrast, in a designated authority system, a subject explicitly identifies a subset (usually one) of its permissions, and the action is allowed only if permitted by that subset of permissions.  
+
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'''.
-
In an ambient authority system, often there is no way to identify a specific permission, so there is no concept of having different permissions.
+
== Notes concerning the definition ==
-
== Comment ==
+
Instead of "naming" an object, capability community often uses the term "designation" of an object.
-
Several access control models were invented and implemented to enable restriction of ambient authority of subjects. Many of them are:
+
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]].
-
* 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 [[authority]] of subjects).
+
The difference between [[ambient authority system]] and the [[designated authority system]] is that:
-
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.
+
* 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 ==
 +
 
 +
* [[Excess authority]]
 +
* [[Ambient authority system]]
== Examples of ambient authority ==
== Examples of ambient authority ==
-
All UNIX processes run by some user have ''ambient authority'' to manipulate all files owned by that user.
+
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 listen to TCP or UDP ports 1024--65535.
All UNIX processes have ''ambient authority'' to send any signal to any other UNIX process.
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.

Latest revision as of 23:43, 2 January 2011

The correct interpretation of this page relies on proper interpretation of words: subject, object, operation and permission.

Contents

Definition

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.

Notes concerning the definition

Instead of "naming" an object, capability community often uses the term "designation" of an object.

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.

The difference between ambient authority system and the designated authority system is that:

  • 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

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.

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