Ambient authority

From Erights

(Difference between revisions)
Jump to: navigation, search
(use level 2 headings)
(Completely replace the definition)
Line 1: Line 1:
== Draft Definition ==
== Draft Definition ==
-
If a [[subject]] can [[operation on object|operate]] on all [[object]]s of a given type, we say that it has '''ambient authority'''.
+
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.  
-
(Note: Dean Tribble and I (Mark S. Miller) are the coiners of the term "ambient authority". I have no idea what the above definition has to do with ambient authority. I am leaving it in place for now, with this note, in case it was a start on something that can be edited into something sensible. I have also changed the heading from "Definition" to "Draft 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.
 +
 
 +
In an ambient authority system, often there is no way to identify a specific permission, so there is no concept of having different permissions.  
== Comment ==
== Comment ==
Line 14: Line 16:
== Examples of ambient authority ==
== Examples of ambient authority ==
-
If we consider UNIX processes run by some user as [[subject]]s and files owned by that user as [[object]]s then all processes have ''ambient authority'' to manipulate all those files.
+
All UNIX processes run by some user have ''ambient authority'' to manipulate all files owned by that user.
-
 
+
-
If we consider UNIX processes as [[subject]]s and TCP ports 1024--65535 as [[object]]s then all processes have ''ambient authority'' to listen to any TCP ports.
+
-
 
+
-
If we consider UNIX processes as [[subject]]s and UDP ports 1024--65535 as [[object]]s then all processes have ''ambient authority'' to listen to any UDP ports.
+
-
 
+
-
If we consider UNIX processes run by some user as [[subject]]s and all executable programs owned by that user as [[object]]s then all these processes have ''ambient authority'' to run any of those programs.
+
-
 
+
-
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).
+
-
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.
+
All UNIX processes have ''ambient authority'' to listen to TCP or UDP ports 1024--65535.
-
If we consider all processes in UNIX as [[subject]]s and also as [[object]]s then all UNIX processes have ''ambient authority'' to send any signal to any other process.
+
All UNIX processes have ''ambient authority'' to send any signal to any other UNIX process.

Revision as of 22:04, 11 June 2009

Draft Definition

A subject may have several different permissions. 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.

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.

In an ambient authority system, often there is no way to identify a specific permission, so there is no concept of having different permissions.

Comment

Several access control models were invented and implemented to enable restriction of ambient authority of subjects. Many of them are:

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

All UNIX processes run by some user have ambient authority to manipulate all files owned by that user.

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.

Personal tools
more tools