Erights - User contributions [en]

Ambient authority

67.124.149.116 — Thu, 11 Jun 2009 18:23:51 GMT

67.124.149.116: /* 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'''.

(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".)

= Comment =

Several access control models were invented and implemented to enable restriction of ambient authority 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 [[authority]] of subjects).
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 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.

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.

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.

Ambient authority

67.124.149.116 — Thu, 11 Jun 2009 18:23:09 GMT

67.124.149.116: /* 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'''.

(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 changes the heading from "Definition" to "Draft Definition".)

= Comment =

Several access control models were invented and implemented to enable restriction of ambient authority 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 [[authority]] of subjects).
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 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.

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.

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.