1 19a-AccessControls

Previous: 18-Authentication.html

1.1 Screencasts

Combined with previous lecture 18-Authentication.html

1.2 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 we have users and groups authenticate to a system and assign them access rights to certain resources on system

1.2.1 Access control principles

1.2.2 Access control policies

• Discretionary access control (DAC): based on the identity of the requester 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 (ABAC): based on the attributes of the user, the resources and the current environment

1.2.3 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: minimize authorization to do a user/process’s 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

1.2.4 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

1.3 Discretionary Access Control (DAC)

https://en.wikipedia.org/wiki/Discretionary_access_control

1.3.1 The Basics

• Often provided using an access matrix
• lists subjects in one dimension (rows)
• lists objects in the other dimension (columns)
• each entry specifies access rights of the specified subject to that object
• Access matrix is often sparse
• Can decompose by either row or column

1.3.2 Access Control Structures

Recall: matrix storage methods in data structures

• Access control matrix
• Access control lists (decomposed by column)
• Capability list or ticket (decomposed by row)

1.3.3 Access matrix and data structure

1.3.3.1 Alternate authorization table

1.3.4 Access control model

Extend the universe of objects to include:

• processes
• devices
• memory locations
• subjects (Ask: what is the impact of this?)

1.3.5 Access control function

1.4 UNIX/Linux

1.4.1 File Concepts

• UNIX files administered using inodes (index nodes)
• An inode:
  • control structure with key info on file (attributes, permissions, …)
  • on a disk: an inode table for all files
  • when a file is opened, its inode is brought to RAM
• Directories form a hierarchical tree
  • may contain files or other directories
  • are a file of names and inode numbers

$ stat file
$ ls -i file

1.4.2 File access

More to come: 19b-Permissions.html

UNIX File Access Control (Important)

• Unique user identification number (user ID)
• Member of a primary group identified by a group ID
• 12 protection bits
  • 9 specify read, write, and execute permission for the owner of the file, members of the group and all other users
  • 2 specify SetID, SetGID
  • 1 is the sticky bit (only owner can remove, delete, …, a directory)
• The owner ID, group ID, and protection bits are part of the file’s inode

1.4.3 User IDs

UNIX File Access Control

“set user ID” (SetUID) or “set group ID” (SetGID)

• system temporarily uses rights of the file owner/group in addition to the real user’s rights when making access control decisions
• enables privileged programs to access files/resources not generally accessible

Sticky bit

• on directory limits rename/move/delete to owner

1.4.4 Superuser (su)

• is exempt from usual access control restrictions

1.4.5 ACL

More to come: 19b-Permissions.html

UNIX Access Control Lists

• Modern UNIX systems support ACLs:
  • FreeBSD, OpenBSD, Linux, Solaris
• Can specify any number of additional users/groups and associated r-w-x permissions
• When access is required
  • select most appropriate ACL:
    • owner, named users, owning/named groups, others
• Check if sufficient permissions for access
• When a process requests access to a file system object two steps are performed:
  • Step 1 selects the most appropriate ACL
  • Step 2 checks if the matching entry contains sufficient permissions

1.5 Mandatory Access Control (MAC)

https://en.wikipedia.org/wiki/Mandatory_access_control

• Similar to DAC or RBAC (below), but only the admin controls the policy.
• A strict hierarchy, where objects have levels, and so do users.
  
  

1.6 Role-based Access Control (RBAC)

https://en.wikipedia.org/wiki/Role-based_access_control

1.6.1 The Basics

• Access based on role, not identity
• Many-to-many relationship between users and roles
• Roles often static

Role-users and roles-object access matrix

1.6.2 Variations

General RBAC, Variations

A family of RBAC with four models

1. RBAC0: min functionality
2. RBAC1: RBAC0 plus role (permission) inheritance
3. RBAC2: RBAC0 plus constraints (restrictions)
4. RBAC3: RBAC0 plus all of the above

1.6.2.1 RBAC0 entities

• User: an individual (with UID) with access to system
• Role: a named job function (tells authority level)
• Permission: equivalent to access rights
• Session: a mapping between a user and set of roles to which a user is assigned

Role-Based Access Control

RBAC

1.6.2.2 Role Hierarchy & Constraints

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 roles in the set
  • Any permission can be granted to only one role in the set
• Cardinality: set a maximum number (of users) with respect to 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

1.6.3 Case study: RBAC system for a bank

Case study: RBAC system for a bank

Case study: RBAC system for a bank

1.7 Summary: DAC vs MAC vs RBAC

1.8 Attribute-based Access Control (ABAC)

https://en.wikipedia.org/wiki/Attribute-based_access_control

• 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

1.8.1 The Basics

1.8.1.1 Types of attributes

• Subject attributes
• Object attributes
• Environment attributes

1.8.1.1.1 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

1.8.1.1.2 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

1.8.1.1.3 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

1.8.2 ABAC compared

• Distinguishable because it controls access to objects by evaluating rules against the attributes of entities, operations, and the environment relevant to a request
• Systems are capable of enforcing DAC, RBAC, and MAC concepts
• Relies upon the evaluation of attributes of the subject, attributes of the object, and a formal relationship or access control rule defining the allowable operations for subject-object attribute combinations in a given environment
• Allows an unlimited number of attributes to be combined to satisfy any access control rule

1.8.3 ABAC Logical Architecture

• A subject requests access to an object
• A.C. is governed by a set of rules (2a):
  • assesses the attr of subject (2b),
  • object (2c) and
  • env (2d)
• A.C. grants subject access to object, if authorized

1.8.4 Comparisons

ACL vs ABAC trust relationships

ACL vs ABAC trust relationships

1.8.5 ABAC Policies

• A policy is a set of rules and relationships that govern allowable behavior within an organization, based on the privileges of subjects and how resources or objects are to be protected under which environment conditions
• Typically written from the perspective of the object that needs protecting and the privileges available to subjects
• Privileges represent the authorized behavior of a subject and are defined by an authority and embodied in a policy
• Other terms commonly used instead of privileges are: rights, authorizations, and entitlements

++++++++++++
Cahoot-19.1

Next: 19b-Permissions.html