Subject, object, operation and permission
From Erights
(The definition of the term `permissions' was simplified not to scare the reader with the notion of a ternary relation. Rather, some well chosen examples may make that more clear.) |
m (added an ?hidden? link to an paulgraham article. Please remove it if it doesnt belong.) |
||
| (5 intermediate revisions not shown) | |||
| Line 1: | Line 1: | ||
| + | We use the terms '''subject''', '''object''', '''operation''' and '''permission''' consistently with a standard access control literature. | ||
| + | |||
== Definition == | == Definition == | ||
| - | From a security point of view, we recognize | + | From a security point of view, we recognize '''subjects''' and '''objects''' |
| - | + | ||
| - | + | '''Subjects''' are active entities (e.g. UNIX processes) with some behavior. '''Subjects''' can designate '''objects''' and try to perform some supported '''operations''' with them. | |
| - | '''Subjects''' are active entities (e.g. UNIX processes) with some behavior. Subjects can designate '''objects''' and try to perform some supported '''operations''' with them. | + | |
What kind of operations can be performed with an object depends on its type. | What kind of operations can be performed with an object depends on its type. | ||
| Line 10: | Line 11: | ||
In general, the set of existing objects and subjects changes over time. | In general, the set of existing objects and subjects changes over time. | ||
| - | '''Permissions''' is a relation that defines which operations on what objects are permitted for particular subjects. | + | '''Permissions''' is a relation that defines which operations on what objects are permitted for particular subjects. One way how to capture permissions is the [[protection matrix]]. |
| + | |||
| + | == Notes == | ||
| + | |||
| + | People (outside capability community) often confuse the following two terms: | ||
| + | * '''permissions''' (defined in this article) | ||
| + | * and [[authority]]. | ||
| + | Real security audit cannot be performed without determining the [[authority]] of particular '''subjects'''. | ||
| + | |||
| + | == See also == | ||
| + | |||
| + | These are standard notions and they are defined in various other places: | ||
| + | * in the [http://www.amazon.com/Operating-Systems-Implementation-Prentice-Software/dp/0131429388/ref=sr_1_14?ie=UTF8&s=books&qid=1245137182&sr=8-14 MINIX Book] (Section 5.5) | ||
| + | * [http://en.wikipedia.org/wiki/Subject_(access_control)#Computer_security in Wikipedia]. | ||
| + | <!-- [http://www.paulgraham.com/reesoo.html] <-- I dont know if this belongs here or not -Zarutian --> | ||
Latest revision as of 15:02, 14 March 2010
We use the terms subject, object, operation and permission consistently with a standard access control literature.
Definition
From a security point of view, we recognize subjects and objects
Subjects are active entities (e.g. UNIX processes) with some behavior. Subjects can designate objects and try to perform some supported operations with them.
What kind of operations can be performed with an object depends on its type.
In general, the set of existing objects and subjects changes over time.
Permissions is a relation that defines which operations on what objects are permitted for particular subjects. One way how to capture permissions is the protection matrix.
Notes
People (outside capability community) often confuse the following two terms:
- permissions (defined in this article)
- and authority.
Real security audit cannot be performed without determining the authority of particular subjects.
See also
These are standard notions and they are defined in various other places:
- in the MINIX Book (Section 5.5)
- in Wikipedia.
