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
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.
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
19a-AccessControls/image25.png
Case study: RBAC system for a bank
Case study: RBAC system for a bank
1.7 Summary: DAC vs MAC vs
RBAC
19a-AccessControls/DACvsMACvsRBAC.jpg
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
