Access Controlssecuresw.dankook.ac.kr/ISS19-2/LN(grad)_2019 SS_05_Access... · 2019-10-13 · Access Control Access control is a system which enables an authority to control access

Software Security

Access Controls (보충 자료)

조성제 (Cho, Seong-je)

Fall, 2019

Computer Security & OS Lab.

Dankook University

Access Control

Access control is a system which enables an authority to control access to areas and resources in a given physical facility or computer-based information system.

In computer security, access control includes authentication, authorization and audit. ● It also includes measures such as physical devices, including biometric

scans and metal locks, hidden paths, digital signatures, encryption, social barriers, and monitoring by humans and automated systems.

In any access control model, the entities that can perform actions in the system are called subjects, and the entities representing resources to which access may need to be controlled are called objects (see also Access Control Matrix).

2 Computer Security & OS Lab, DKU

Identification, Authentication, Authorization

Access control systems provide the essential services of identification and authentication (I&A), authorization, and accountability where:

identification and authentication determine who can log on to a system, and the association of users with the software subjects that they are able to control as a result of logging in;

authorization determines what a subject can do;

accountability identifies what a subject (or all subjects associated with a user) did.


Access Control (AC)

Its function is to control which (active) subject have access to a which (passive) object with some specific access operation.

Subjects operate on behalf of principles

● Each subject must be bound to a unique principle

● A Principal may be bound to several subjects

● Examples

− Principle: user ID

− Subject: process ID


subject Access Operation

object

Access Control (AC)

‹Common Assumption

● • System knows who the user is

− User has entered a name and password, or other info

● • Access requests pass through gatekeeper

− OS must be designed monitor cannot be bypassed

Decide whether user can apply operation to resource


Motivation of Access Control

Why do we need access control?

Confidentiality, a user should be able to deny other users read access to his files ● No READ

Integrity, a user should be able to protect his files from modification or deletion by other users ● No WRITE

Help users to avoid unintentional change of important system files

Help users to avoid unintentional change of important personal files, e.g., photos


Two important principles

Principle of least privilege ● A user or process should only have access to resources that are necessary

− More stability – processes can not affect each other more than necessary and only affect a limited part of the system

− More security – Vulnerabilities on one application can not be used to exploit other parts of the system

Separation of duties ● Security critical functionality must be performed by more than one user

● Prevents fraud and errors

● Sometimes difficult to achieve

● Example: designer/implementer should not be same as tester

● Example 2: Control of nuclear missile launch


Access Controls

DAC (Discretionary Access Control)

MAC (Mandatory Access Control)

Multi-level Security

• Bell/LaPadula model (BLP model)

• Biba model

RBAC (Role-based Access Control)

Computer Security & OS Lab, DKU 8

Discretionary AC

Restricts access to objects based solely on the identity of users who are trying to access them.


DAC

Data owners can create and modify matrix of subject/object relationships (e.g., ACLs)

● Access Control List (ACL)

− Store column of matrix with the resource

− Associate list with each object

− Check user/group against list

− Relies on authentication: need to know user


DAC • Access governed by normal users • Owner of a resource can designate

permissions • Standard model for Unix, Linux,

Windows, etc. • Access control is at the discretion of

the user • Implements user’s policy

Linux Access Control Introduction

Linux access control involves the kernel controlling

● Processes (running programs), which try to access...

● Resources (files, directories, sockets, etc)

For example:

● Apache (process) can read web files

● But not the /etc/shadow file (resource)

Traditional methods do not clearly separate the privileges of users and applications acting on the users behalf, increasing the damage that can be caused by application exploits.

So, how should these decisions be made?


ACL


File permissions

Problems with DAC

DACs are inadequate for enforcing information flow policies

● The provide no constraint on copying information from one object to another

Example: Consider Alice, Bob, and Eve.

● Alice has a file X that she wants Bob to read, but not Eve.

● Alice authorizes Bob via the following Access Control Matrix

● Bob can subvert Alice’s discretion by copying X into Y.

− Bob has write privileges, and Eve has read privileges for Y.

● This case is a simplistic version of what can be much more pathological… The Trojan Horse…


DAC and Trojan Horses

What if Bob isn’t bad… Eve could still read X by convincing Bob to use a program carrying a Trojan Horse (Troy)

Consider the new access control matrix:

● Eve has created Troy and given it to Bob, who has execute privileges

● Troy inherits Bob’s read privileges to X, and write privileges to a file Y (perhaps public)

● Eve has read privileges to file Y

Trojan Horses perform normal “claimed” operations, but also participates in subversive activities


Solution: Impose Mandatory Access Controls

(MAC) that cannot be bypassed.

DAC and Trojan Horses


DAC

Owner of object sets access rights

● Regular users can adjust the policy

● Subjects has total control over objects

Object owner has full power

● Complete trust in users

● Decisions are based only on user id and object ownerships

− Decision made based on identity of requestor and access rules

● Impossible to control information flow

Discretionary means anyone with access can propagate information


MAC

Mandatory Access Control (MAC)

● When a system mechanism controls access to an object and an individual user cannot alter hat access, the control is mandatory access control.

● MAC, typically requires a central authority

MLS concepts

● ‹Military security policy

− Classification involves sensitivity levels, compartments

− Do not let classified information leak to unclassified files ‹

● Group individuals and resources

− Use some form of hierarchy to organize policy

● ‹Other policy concepts

− Separation of duty

− “Chinese Wall” Policy

MLS

● BLP model

● Biba model


Multi-level Security (MLS)

The term multi-level arises from the defense community's security classifications: Confidential, Secret, and Top Secret. ● Individuals must be granted appropriate clearances before they can see classified

information. Those with Confidential clearance are only authorized to view Confidential documents.

● The rules that apply to data flow operate from lower levels to higher levels, and never the reverse.


Information Security Level

Bell-La Padula Model (BLP)

Bell/LaPadula enforces confidentiality

● data cannot flow from a higher level to a lower level.

● No read up, No write down


Security Levels on objects are called Classifications. Security Levels on subjects are called Clearances.

BLP model

MAC policies are attribute-based, meaning access can be defined based on properties/attributes of both the user and any item the user is viewing.


MLS access rules are always combined with conventional access permissions (file permissions). For example, if a user with a security level of "Secret" uses DAC to block access to a file by other users, this also blocks access by users with a security level of "Top Secret". A higher security clearance does not automatically give permission to arbitrarily browse a file system. Users with top-level clearances do not automatically acquire administrative rights on multi-level systems. While they may have access to all information on the computer, this is different from having administrative rights.

BLP and Trojan Horses

Return to the Trojan Horse problem:

● Alice and Bob are secret level users, Eve is an unclassified user

● Alice and Bob can have both secret and unclassified subjects (programs)

● Eve can only have unclassified subjects

● Alice creates secret file X

● Simple security prevents Eve from reading X directly

● Bob can either have a secret (S-Troy) or an unclassified (U-Troy) Trojan-Horse carrying program

● S-Troy: Bob running S-Troy will create Y, which will be a secret file.

− Eve’s unclassified subjects will not be able to read Y.

● U-Troy: Bob running U-Troy won’t be able to read X, and so won’t be able to copy it into Y.

Thus BLP prevents flow between security classes

One problem remains: Covert Channels…


Biba model

Biba enforces integrity


BLP vs. Biba


MAC

Global (organizational) policy

The system (not you) decided how the object will be shared

● Regular user cannot adjust the policy = End-user cannot set controls

Only trust in administrators

● Object owner CAN have some power

Labeled protection

● Every object has classification label maintained by the system, kept when copied

● Every process has clearance label set by system – determines access rights

● Based on comparing security labels of system resources with security clearances of entities accessing the resources

● Decision made by testing labels associated with process and resources against system policy rules

Cleared entity cannot pass on access rights to another entity

Makes information flow control possible


DAC vs MAC

Source: Evolution of access control models for protection of patient details: a survey


DAC vs MAC


Role-based AC (RBAC)

Many organizations base access control decisions on “the roles that individual users take on as part of the organization”.

They prefer to centrally control and maintain access rights that reflect the organization’s protection guidelines.

With RBAC, role-permission relationships can be predefined, which makes it simple to assign users to the predefined roles.

The combination of users and permissions tend to change over time, the permissions associated with a role are more stable.

RBAC concept supports three well-known security principles:

● Least privilege

● Separation of duties

● Data abstraction


Role-based AC (RBAC)

Users have access to at least on role

● They assume on role at a time

Each role has defined rights

● Processes (subjects) only have the access rights of the role they were invoked from


RBAC


RBAC

Privilege

● Roles are engineered based on the principle of least privileged.

● A role contains the minimum amount of permissions to instantiate an 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.

Core Components

● Permissions (prms)

− Assigned Permissions

− Object Permissions

− Operation Permissions

● Sessions: Each session is a mapping of one user to possibly many roles

− User Sessions: The mapping of user u onto a set of sessions.

− Available Session Permissions: Permissions available to a user in a session.

− Session Roles: The mapping of session s onto a set of roles


RBAC

Access depends on role/function, not identity ● Example: Allison is bookkeeper for Math Dept. She has access to financial

records. If she leaves and Betty is hired as the new bookkeeper, Betty now has access to those records. The role of “bookkeeper” dictates access, not the identity of the individual.

Advantages of RBAC ● Allows Efficient Security Management

− Administrative roles, Role hierarchy

● Principle of least privilege allows minimizing damage

● Separation of Duties constraints to prevent fraud

● Allows grouping of objects

● Policy-neutral - Provides generality

● Encompasses DAC and MAC policies


RBAC

Is RBAC a discretionary or mandatory access control?

● RBAC is policy neutral; however individual RBAC configurations can support a mandatory policy, while others can support a discretionary policy.

Role Hierarcies

Role Administration


Project Supervisor

Test engineer Programmer

Project Member

RBAC models

RBAC0 : Base model

● User, roles, permission, session

RBAC1 : Role Hierarchies

● Allow inheritance

RBAC2 : Constraints

● Mutually exclusive roles (separation of duties)

● Cardinality (e.g., only one manager per project, only a certain number of roles for each user)

● Prerequisite (You must have a subordinate role – allows implementation of least privilege)

RBAC3 : RBAC1 + RBAC2

● Combining hierarchies with constraints


RBAC (NIST Standard)


Permissions

Users Roles Operations Objects

Sessions

UA

user_sessions

(one-to-many) role_sessions

(many-to-many)

PA

An important difference from classical models is that

Subject in other models corresponds to a Session in RBAC

RBAC with General Role Hierarchy


Permissions


Sessions

UA

user_sessions

(one-to-many) role_sessions

(many-to-many)

PA

RH

(role hierarchy)

Constrained RBAC


Permissions


Sessions

UA

user_sessions

(one-to-many)

PA

RH

(role hierarchy) Static

Separation

of Duty

Dynamic

Separation

of Duty

Separation of Duties

No user should be given enough privileges to misuse the system on their own.

Statically: defining the conflicting roles

Dynamically: Enforcing the control at access time


Partial Orderings

Set of security levels L

A partial ordering ≤ on a set L is a relation on L x L which is ● Reflexive: a ≤ a, for all 𝑎 ∈ 𝐿

● Transitive: if a ≤ b and b ≤ c then a ≤ c, for all 𝑎 ∈ 𝐿

● Antisymmetric: if a ≤ b and b ≤ a then a=b, for all 𝑎 ∈ 𝐿

Example: ● Powerset P(X) with subset relation as partial ordering


Lattice of security levels

A lattice can answer two questions: ● Given two objects at different security levels, what is the minimal security

level a subject must have to access both?

● Given two subjects at different security levels, what is the maximum security level an object can have so that it can be accessed by both subjects?

Definition: A lattice (L, ≤) consists of a set L and a partial ordering ≤. For 𝑎, 𝑏 ∈ 𝐿 there is a least upper bound 𝑢 ∈ 𝐿 and a greatest lower bound 𝑙 ∈ 𝐿.

● a ≤ u, b ≤ u, and ∀v ∈ L : (a ≤ v ∧ b ≤ v) ⇒ (u ≤ v)

● l ≤ a, l ≤ b, and ∀k ∈ L : (k ≤ a ∧ k ≤ b) ⇒ (k ≤ l)

We say that b dominates a if a ≤ b

Powerset with subset relation as partial ordering is a lattice


RBAC

Assigns permissions to particular roles in the organization and then users are assigned to roles ● Considered a more “real-world” approach

Based on roles that users have within system and on rules stating what accesses are allowed to users in given roles

Access decisions defined against roles rather than individual requestors

Roles needs provisioning and maintenance


MAC vs DAC vs RBAC


DAC vs. MAC vs. RBAC


DAC MAC RBAC

•Highly Flexible •Not as secure as MAC •Easier to implement

•Doesn’t scale well •ACL explosion possibility •Prone to mistakes

• It is OK to modify object

attributes • It is NO to modify subject

attribute by creating user

•Most secure •Easy to scale

•Less flexible (Not flexible) •Limited user functionality •High admin overhead

•Comparatively less easier

to implement • It is NO to modify object

attributes • It is NO to modify subject


•Scalable •Flexible – user &

permission are loosely coupled •Less administration

required •Possibility of role

explosion •Unable to accommodate

real-time context • It is NA to modify object

attributes • It is OK to modify subject


The Comparative Table of the Historical Access Control Models


The Comparative Table of the Historical Access Control Models


References

Access Control and Operating System Security ● https://crypto.stanford.edu/cs155old/cs155-spring09/hw_and_proj/lectures/lecture9.pdf

Cyber Security, Lecture for July 2, 2010, Access Control, Dr. Bhavani Thuraisingham

2008-10-15 Red Hat Deep Dive Sessions: SELinux ● https://www.slideshare.net/ShawnWells4/20081015-red-hat-deep-dive-sessions-selinux

EIT060 - Computer Security, Access Control ● https://www.eit.lth.se/fileadmin/eit/courses/eit060/lect/Lect5.pdf

Access Control Models: From the real-world to trusted computing, WinLab

Role-Based Access Control, Overview ● https://csrc.nist.gov/CSRC/media/Presentations/Role-based-Access-Control/images-media/Role-

based%20Access%20Control2.pdf

Analysis of Common Access Control Models and Their Limitations in Cloud Computing Environment

SWOT analysis of access control models

Evolution of access control models for protection of patient details: a survey


https://crypto.stanford.edu/cs155old/cs155-spring09/hw_and_proj/lectures/lecture9.pdf






https://www.slideshare.net/ShawnWells4/20081015-red-hat-deep-dive-sessions-selinux













https://www.eit.lth.se/fileadmin/eit/courses/eit060/lect/Lect5.pdf



https://csrc.nist.gov/CSRC/media/Presentations/Role-based-Access-Control/images-media/Role-based Access Control2.pdf












Documents

Access Controlssecuresw.dankook.ac.kr/ISS19-2/LN(grad)_2019 SS_05_Access... · 2019-10-13 · Access Control Access control is a system which enables an authority to control access