Access Control Flashcards
Objective
prevent legitimate users from accessing resources in an unauthorized manner
enable legitimate users to access resources in an authorized manner
Access Control
Measures that implement and assure security services in a computer system
Access Control Context
Authentication -> validate credentials from claimant match subscriber to system
Authorization -> granting rights or permissions
Audit -> independent review to ensure compliance of rules over resources and activities
Access Control Policies - Discretionary Access Control
Identity plus access rules to determine what entity can do
Entity can assign permissions to other entities
Processes can inherit user’s access rights, too flexible
Enforced using Access Matrices
M_i = subjects
M_j = objects
M_i,j = access rights from i over j
May be decomposed by column to have a Access Control List for a given resource/object
ACL might have default entry for world users (should be read-only)
Decomposition by rows -> Capability tickets (what a user is allowed to do)
Harder to check Capability tickets than ACL’s and tickets can be forged if not handle in centralized repository
Solution -> Authorization table, one row subject, access right, object
Types of permissions/access rights
Read -> view, copy, print
Write -> add, modify, delete
Execute
Delete
Create
Search -> with partial view
Access Control Policies - Mandatory Access Control
Comparing security labels to security clearances
One entity with clearance cannot assign clearance to resource to another entity
Also includes DAC
Access Control Policies - Role-based Access Control
Based on the role the user has assigned and the rules that defined which resources are allowed for those roles
NIST FIPS PUB 140-3
The Access Control Matrix has the same structure as the DAC ACM, with roles as subjects
Rbac0 (base model) -> Rbac1 (role hierarchies)
Rbac0 (base model) -> Rabc2 (constraints)
Rbac1/2 -> Rbac3 (Consolidated model)
hierarchies -> one role to inherit permissions from another role
constraints -> restrict the ways in which the components may be configured
Access Control Policies - Attribute-based Access Control
Based on attributes of the user, resource to be accessed, and environmental conditions
Elements of access control
Subject
entity (user or application) that can access objects
Takes the access rights from its initiator
Held accountable in an audit trail
Classes of subject:
Owner -> creator of resource
Group -> group of users, user may belong to multiple groups
World -> anon, access to the system
Object
Entity that contains or receives information
Access Rights
Way in which a subject may access an object
DAC - Authorization table
Rows have subject, access right and object
Object can include -> processes, devices, memory locations or regions, subjects
delete a process, stop, wake up
read/write to protected memory locations
read/write, control, block/unblock devices
grant or delete access rights to subjects
New access rights: owner, control and a copy flag (if transferred access right can be transferred again)
DAC - Protection domains
associate capabilities with a protection domain. A set of objects together with access rights to those objects.
User can spawn a subprocess with a subset of the access rights as a new protection domain
UNIX, user mode vs kernel mode, to execute commands that require higher privilege
UNIX File Access Control
Final permission bit “sticky”
files -> no longer used
directory -> only owner can rename, move or delete
superuser -> exempt of file access control
Role-based access control
Rbac0
User -> with userid
Role -> named job function
Permission -> mode of access to one or more objects (access right, privilege, authorization)
Session -> mapping of user -> activated subset of roles from user
RBac0
use inheritance to enable one role to implicitly include permissions from a subordinate role
Rbac1
Mutually exclusive roles: user can only have one role from a set assigned (per session or statically) any permission can only be granted to one of the roles in the set (separation of duties)
Cardinality limiting the number of roles per session or per user
Pre-requisite role only if user already has role x can be assigned to role y
Attribute Based Access Control
Can defined authorizations that express conditions on properties of both the resource and the subject
Main obstacle is cost of performance evaluating predicates
Used in cloud services and web services extensively
Attributes
characteristics of the subject, object, env and operation
Policy
which actions are subjects allowed to do to objects
ICAM -> framework to manage digital identities, credentials and access control.
RBAC - SSD/DSD
Static separation of duties (SSD)
handling the user assignment and the role hierarchy
Dynamic separation of duties(DSD)
the role being assigned in the session
