AC Flashcards
The Access Control Model
Guards control access to valued resources.
Access Control
-
Discretionary access control: the owner of an object has the possibility to protect an object against access.
I.e.: an entity can specify what other entities may or may not access an object, and in what ways these entities may access the object. - Mandatory access control: the system always checks an entity’s rights to access an object. Neither an entity nor the owner of an object can ever override or change the decision made by the system.(Data tend to migrate up in security level)
DAC - Drawbacks
Does not provide real assurance on the flow of information in a system.
Does not impose any restriction on the usage of information by a User once the User has received it.
Objects are under control of users and can e.g. be passed on to other Users.
Information can be copied from one Object to another, so access to a copy is possible even if the owner of the original does not provide access to it.
Principals and Objects
Principal: an entity making a request
- (Program, User; in Unix: User Id)
Object: an item to which access is requested.
- (Byte in memory, file, printer, etc.)
ACLs
Access control
- Enforce Restrictions :
- Authentication: Verify Indentity.
- Authorisation: Check if access complies with policy
Access Control Matrices can, for instance, be implemented using Access Control Lists (ACLs) :
- Each Object has ist own ACL, specifying the rights of principals, e.g.:
allow read,write: Alice,Jim
allow read: John,Jim,Bob
deny read: Eric
Capabilities
Another option instead of an ACL is a „Capability“:
- unforgeable “ticket’’, proof for the right to access an object (at a given time):
- Example:
- *[(O,read)] means: the owner of the ticket may read object O.**
Implementation variants for capabilities:
- Cryptographic Approaches
- OS maintains Capabilities for Users
- Pointer: Ticket is a Pointer into a (huge) address space, where the actual address cannot be guessed
- Type-based approaches: Tickets are types in a type-secure language
ACLs vs. Capabilities
Capabilities have benefits in performance
- ACLs: Decide at each access (late binding).
- Capabilities: decide once att the beginning (early binding).
Delegation of rights to other principals :
- ACLs: generally not possible without support by OS Capabilities:
- can be copied, passed, …
ACLs vs. Capabilities 2
Revocation of rights:
- ACLs: easy.
- Capabilities: hard to impossible (often based on expiry date)
Often hybrid approaches are used in real life :
- A capability is granted based on ACL
Role-Based AC
A user has access to an object based on the assigned role.
Roles are defined based on job functions.
Permissions are defined based on job authority and responsibilities within a job function.
Operations on an object are invocated based on the permissions. The object is concerned with the user’s role and not the user.
Privilege
Roles are engineered based on the principle of least privileged
A role contains the minimum amount of permissions to instantiatean object.
A user is assigned to a role that allows him or her to perform only what’s required for that role.
No single role is given more permission than the same role for another user.
Further refinements of role-based systems:
- Constraints
- Hierarchies (e.g. for implementing responsibilities)
- …