Access Control and Information

Ownership

Lecture 6
 Access Control
• “The prevention of unauthorized use of a resource,
including the prevention of use of a resource in an
unauthorized manner”.

• Central element of computer security.

• Assume have users and groups

– authenticate to system
– assigned access rights to certain resources on system
 What goes into system security?
• Authentication (password/crypto/etc.)
– Who are you?
• Authorization (Access control)
– What are you allowed to do.
– Focus is the policy
• Enforcement Mechanism
- How its policy implemented/enforced

Today we are mostly interested in #2, will touch on #3

Note: split between policy and mechanism sometimes a false
dichotomy.
 Night Club Example
• Authentication
– ID Check
• Access Control
– Over 18 - allowed in
– Over 21 - allowed to drink
– On VIP List - allowed to access VIP area
• Enforcement Mechanism
– Walls, Doors, Locks, Bouncers
 Night Club Example: More
Interesting Phenomena
• Tickets
– Name or anonymous?
– Date
• What if you want to leave and come back
– Hand stamp or bracelet
 Operating Systems: Our focus today
• Most heavily studied area for access control
• First computers where single user/no network
• Timesharing systems introduced need for access control
– studied heavily in the 70’s and 80’s.
• Still an open research area, why?
– First 20 years: restrict what a user can do with data, focus on
military problems, thought problem was malicous users
– Last 10: Malicous applications the primary problem.

• Another answer: Right Access control policy dictated by Usage

models, Threat Model, Applications -- we still have lots to learn about
how programs are built, how people use them.
Access Control Principles
 Access control policies
• Discretionary access control (DAC): based on the identity of
the requestor and access rules
• Mandatory access control (MAC): based on comparing
security labels with security clearances (mandatory: one with
access to a resource cannot pass to others)
• Role-based access control (RBAC): based on user roles
• Attribute-based access control: based on the attributes of the
user, the resources and the current environment
 Access Control Requirements
• Reliable input: a mechanism to authenticate
• Fine and coarse specifications: regulate access at varying levels
(e.g., an attribute or entire DB)
• Least privilege: min authorization to do its work
• Separation of duty: divide steps among different individuals
• Open and closed policies: accesses specifically authorized or
all accesses except those prohibited
• Administrative policies: who can add, delete, modify rules
 Access Control Elements
• Subject: entity that can access objects
– a process representing user/application
– often have 3 classes: owner, group, world
• Object: access controlled resource
– e.g. files, directories, records, programs etc
– number/type depend on environment
• Access right: way in which subject accesses an
object
– e.g. read, write, execute, delete, create, search
An access matrix
Role-Based
Access
Control
Access based on
‘role’, not identity

Many-to-many
relationship between
users and roles

Roles often static

 Example of role hierarchy
• Director has most privileges
• Each role inherits all
privileges from lower roles
• A role can inherit from
multiple roles
• Additional privileges can be
assigned to a role
 Constraints
• A condition (restriction) on a role or between roles
– Mutually exclusive
• role sets such that a user can be assigned to only one of the
role in the set
• Any permission can be granted to only one role in the set
– Cardinality: set a maximum number (of users) wrt a
role (e.g., a department chair role)
– Prerequisite role: a user can be assigned a role only if
that user already has been assigned to some other role
 Attribute-based access control
• Fairly recent
• Define authorizations that express conditions on
properties of both the resource and the subject
– Each resource has an attribute (e.g., the subject that created
it)
– A single rule states ownership privileges for the creators
• Strength: its flexibility and expressive power
• Considerable interest in applying the model to cloud
services
 Types of attributes
• Subject attributes
• Object attributes
• Environment attributes
 Subject attributes
• A subject is an active entity that causes
information to flow among objects or
changes the system state
• Attributes define the identity and
characteristics of the subject
– Name
– Organization
– Job title
 Object attribute
• An object (or resource) is a passive
information system-related entity
containing or receiving information
• Objects have attributes that can be
leveraged to make access control decisions
– Title
– Author
– Date
 Environment attributes
• Describe the operational, technical, and even
situational environment or context in which the
information access occurs
– Current date
– Current virus/hacker activities
– Network security level
– Not associated with a resource or subject
• These attributes have so far been largely ignored
in most access control policies
 Sample ABAC scenario
1. A subject requests access
to an object
2. AC is governed by a set of
rules (2a): assesses the attr
of subject (2b), object (2c)
and env (2d)
3. AC grants subject access to
object if authorized
 Identity, Credential, and Access
Management (ICAM)
• A comprehensive approach to managing and
implementing digital identities, credentials, and access
control
• Developed by the U.S. government
• Designed to create trusted digital identity representations
of individuals and nonperson entities (NPEs)
• A credential is an object or data structure that
authoritatively binds an identity to a token possessed and
controlled by a subscriber
• Use the credentials to provide authorized access to an
agency’s resources
 1. Connects digital identity
to individuals

ICAM

2. Data structures that binds

a token possessed
by a subscriber

4. Identity verification of
individuals from external
organizations 3. Management of how access
is granted to entities
Abstract Models of Access
Control
 Subjects and Objects
• Subjects
– can be processes, modules, roles
• Objects
– can be files, processes, etc.

• Authentication often used to bootstrap subjects, but not

necessary.
– e.g. process assumes identity of one subject, then another.
 Elementary Forms
• Authentication = Authorization
– e.g. safes
• Whitelists/Blacklists (Single object, multiple Subjects)
– Examples: Spam prevention
– Blacklists:
• Default on (fail open)
• Hard to reason about who can access system
– Whitelists:
• Default off (fail closed)
• Have to deal with adding whitelist entries
• Challenges
• Hard to manage if rapidly changing set of principles
• Both can grow quite large
 Adding Access Rights
• Access Rights
– e.g. Simple: Read, Write
– e.g. Complex: execute, change ownership
Objects

A B C D
alice r r/w r -
bob r r - r/w
subjects
charlie - - w -
dave r/w - w
 Grouping
• Subjects
– Groups e.g. staff = {alice,dave}, students = {bob, charlie}

• Objects
– Types e.g. system_file = {A,B}, user_file = {C,D}

• Can have compound names

– e.g. in AFS talg:friends, system:backup