INSE 6130

INSE 6130: Operating Systems Security

Outline

• Instructor: Prof. Lingyu Wang
• Website: INSE6130 2020 Fall
• Email: wang@ciise.concordia.ca

  Include "INSE 6130" in the subject

• Office:
  • Fridays 16:30 - 17:30
• Coursebook
  • M.Bishop, Computer Security. Art and Science (2nd Edition), Addison-Wesley 2018.
• Course Description:

  System security, MS Windows security, linux security, unix security, embedded and real-time OS, system reliability, OS security mechanisms, security administration, delegation of authority, group policy design, security configuration, password requirements, security services, protection models, protection levels, protection domains, capabilities, sharing, system kernel security, resource control, secure booting, firewalls and border security, security models and policies, security levels, authentication, confidentiality, integrity, access control strategies access matrix, access control list, mandatory, discretionary, monitoring, auditing, accountability, privilege, account security, file system protection, registry security, threat analysis, security attacks, security-hardened operating

---

Introduction

What is computer security?

• Physical security and information security

Overview of all perspectives of system security

• Objectives

  • Confidentiality (Secrecy)
    • What: keeping data and resources hidden
    • How: encryption
  • Integrity
    • What: data integrity and origin integrity (authentication)
    • How: digital signature and ?
  • Availability (Denial of Service)
    • What: enabling access to data and resources

• Classes of Threats

  • Disclosure: snooping(sniffing) -> confidentiality
  • Deception: modification, spoofing (masquerading), repudiation of origin, denial of receipt -> integrity
  • Disruptoin: modification -> availability
  • Usurpation(taking control of system): modification, spoofing, delay, denial of service -> confidentiality, integrity, availability

• Policies and Mechanisms

  • Policies define "security" for the system: what can do, what cannot do
    • Given by natural language, math, special languages
  • Mechanisms enforece policies
    • Technical or procedural
  • OM-AM (by Ravi Sandhu)
    • Objective (policy): e.g. confidentiality
    • Model: A model is an abstract conceptual description of the objective. e.g. ACM
    • Architecutre: How to implemente the model. e.g. Client-Server
    • Mechanism: Mechanism is a low level implementation. e.g. Encryption

• Ways for achieving security

  • Prevention
    • Prevent attacks from violating security policy
    • Prevention not always work
  • Detection
  • Recovery
    • Stop attack, assess and repair damage
    • Continue to function correctly even if attack succeeds (e.g. Amazon cannot stop service to recover)

• Trust and assumptions

  • They underlie all aspects of security
  • For policies: unambiguously partiion system states, correctly capture security requirements
  • For mechanisms: assumed to enforce policy, work correctly

• Types of Mechanisms

  • Three cases
    • secure
    • precise
    • broad: some secure states are not reachable, some reachable states are not secure. This is the most common situation.
  • Policy should cover security.

• The role of trust, assurance, operational issues, human issues

  • Assurance
    • Specification: what is secure
      • Requirements analysis
      • Statement of desired functionality
    • Design
    • Implementatioin
  • Operational issues
    • Cost-Benefit analysis
      • Is it cheaper to prevent or to recover
    • Risk analysis
      • Should we protect something
      • How much should we protect is
    • Laws and Customs
  • Human Issues
    • Organizational Problems
      • Power and responsibility
      • Financial benefits
    • People problems
      • Outsiders and insiders
      • Social engineering: get information from person to go further

• How them tie together

---

Access Control Matrix

“How do I describe the security of any computer system… mathematically?”

- So we have the Access Control Matrix model

- Access control is who can do what to whom

ACM (Access Control Matrix)

Q: How to describe a system at any given time?

A: Protection state of a system

1. What is state of a system: Collection of current settings and valus of a system. e.g.: values of memory locations, secondary storage, registers, and other components of an OS
2. What is protection state of a system: Subset of a state that is relevant to security. e.g.: access control settings (who can do what to whom)

Q: How to mathematically represent a protection state?

A: Access cnotrol matrix

1. ACM is a matrix describing rights of subjects over objectives
2. ACM is an abstract model
   • Subject, object, and right could be anything

Definition of ACM

	$o_1$	$o_2$	$\ldots$	$o_m$	$s_1$	$s_2$	$\dots$	$s_n$
$s_1$	$r_1$	$r_1r_2$			$r_3$
$s_2$		$r_3r_4r_5$	$r_4$
$\ldots$
$s_n$

• Subjects: $S=\{s_1, \ldots, s_n\}$
• Objects: $O=\{o_1, \ldots, o_m\}$
• Rights: $R=\{r_1, \ldots, r_k\}$
• Matrix entries: $A[s_i, o_j]\subseteq R$
• Interpretation: $A[s_i, o_j]=\{r_x,\ldots, r_y\}$ means subject $s_i$ has rights $r_x, \dots, r_y$ over object $o_j$
• Object set always encloses subject set

Transition in ACM

• Why transition
  • The protection state of a system will change
  • Such change is modeled as ACM state transition
• Elements of transition
  • $X_i$ : ACM in the starting state
  • $X_{i+1}$: ACM in the ending state
  • Command $\tau$ : the action that causes this state transition
• Put it together: $X_i \vdash_{\tau} X_{i+1}$

Primitive Operations

Primitive Operations are the basic changes you can make to ACM.

• Create/destroy/enter/delete its elements:
  • create/destroy subject $s$
  • create/destroy object $o$
  • enter/delete $r$ into $A[s, o]$

Special Rights

• Copy
• Own

Command

Command is a fixed sequence of primitive operations.

• Command with Conditions
• Mono-operations Command
• Mono-conditional Command

note

Conditions cannot be negative or connected by "or"

Principle of Attenuation of privilege

• One shouldn't be able to give out rights he/she does not posses except owner.
• The owner right implies all other rights.
  • Owner can give itself rights, then give the right to others, and finally delete its rights.

Question

Given an ACM and all the allowed commands, how to decide whether a subject will ever posses a right over an object?

---

Foundational Results

“Can I determine whether Can I determine whether any computer system is computer system is secure?” (asked by Harrison Ruzzo and Ullman)

- So we have the HRU result

Safety Problem

note

If a subject who does not initially possess a right $r$ can never obtain $r$, then the system is safe with respect to $r$ (legitimate delegation of $r$ are ignored).

Q: Can we write a program to decide the safety of any protection system?

A: Safety problem is undecidable. (Special cases may be decidable)

Take-Grant Protection model

Take-Grant Protection model is a protection system with a specific set of commands. It decidable with a linear time complexity in the size of the system.

---

Access Control Mechanism

ACM is good for theoretical study but bad for implementation.

Access Control List(ACL)

An ACL stores the non-empty elements of each column with an object.

#TODO

• 'Closed World' assumption
  • Denied unless explicitly granted
• Identical rows
  • Use groups or wildcards to merge them
• Who can modify ACL?
  • Creator of the file ACL or
  • who have been granted modify right

Capability Lists (C-List)

Rows or access control matrix stored with subjects.

#TODO

• The key challenge in implmentation is to prevent process/user from altering capabilities.
  • Kernel space versus User space
  • Put C-List inKernel space

ACL versus C-Lists

• Equivalent in theory
• Differ in efficiency in answering
  • Which object can be accessed by a given subject? (C-List win)
  • What subjects can access a given object? (ACL win)

Role-Based Access Control (RBAC)

ACL/C-List full mapping would be too complicated, so introduce RBAC (Role).

info

Why role? Because rights usually depend on role (job function) instead of idenity.

1. $\text{RBAC}_{0}$

   • Four sets: $U, R, P, S$
   • Two many-to-many relations $UA, PA$ (User assignments, Permission assignments)
     • $US\subseteq U\times R$
     • $PA\subseteq P\times R$
   • $\text{user}(s)$: which user does a session $s$ belong to
   • $\text{roles}(s)$: which roles the session $s$ has activated

2. $\text{RBAC}_{1}$: $\text{RBAC}_{1}$ = $\text{RBAC}_{0}$ + role hierarchy

   • If $r_1\leq r_2$ then
   1. Any user assigned to $r_2$ can activate $r_1$
   2. Activating $r_2$ gives user the all of $r_1$'s permissions

3. $\text{RBAC}_{3}$: $\text{RBAC}_{3}$ = $\text{RBAC}_{1}$ + constraints

   • No session can activate both TA and student

---

Security Policies and Confidentiality Policies

Security Plicies are unambiguous statements.

Define Security Policies

• Positive authorizations with the Closed World assumption
• Negative authorizations with the Open World assumption
• A mixture of the two, with conflicts resolution meta-policies

Security Policty Defines Security

note

Under security policies, a 'secure' system is one that

1. Only starts from authorized states
2. Never enters any unauthorized states

Types of Security policy

1. Confidentiality policy
2. Integrity policy
3. Availability policy

Most applications require combinations of these.

Types of Access Control Policies

1. Descretionary Access Control (DAC)
   • Access is based on owner's discretionary
   • Standard Unix security
2. Mandatory Access Control (MAC)
   • System controls accesses and users cannot alter

Lattice

• LUB: least upper bound
• GLB: greatest lower bound
• Lattice is a poset whose elements all have unique LUBs and GLBs.

Denning's Axioms

Security levels form a lattice.

• A security level is a pair (clearance/classification, category)

Bell-LaPadula (BLP) model

Objective: Information cannot flow downwards. This implies:

1. No read up
2. No write down

The BLP policy has two parts to achieve this goal.

1. Simple Security Policy (Read)
   • Subject $s$ can read object $o\iff L(s)\geq L(o)$.
   • This is the "no read up" rule.
2. *-Property (Write)
   • Subject $s$ can write object $o\iff L(s)\leq L(o)$.
   • This is the "no write down" rule.

---

Integrity Policies and Hybrid Policies

Biba model

Objective: Information cannot flow upwards. This implies:

1. No read down
2. No write up

General Formal

• $S$: the set of subjects
• $O$: the set of Objects
• $I$: the set of integrity levels
• $i(s)\in I$: integrity level of $s$ where $s\in S$
• $i(o)\in I$: integrity level of $o$ where $o\in O$
• $s\: \underline{r}\: o$: $s$ can read $o$
• $s\: \underline{w}\: o$: $s$ can write $o$
• $s\: \underline{x}\: s$: $s$ can execute $s$

Strict Integrity Policy

Low-Water-Mark Policy

1. Subject Low-Water-Mark Policy
2. Object Low-Water-Mark Policy

Information Transfer Path

Combining Biba and BLP

1. What if they are exactly reversed
2. What if they are exactly the same

Chinese Wall Policy (Hybird Policy)

• Place non-conflicting objects inside walls
• Each analyst can only access objects inside a walls
• History-based access control

Organization of Objects

• Objects
  • Sanitized objects: Public information that never results in conflicts of interests.
  • Unsanitized objects: Everyting else
• Company dataset (CD)
• Conflict of interest class (COI)
• One special CD in one special COI for all sanitized objects.

CW-Simple Security Conditions

• Initially, a subject can read any CD in any COI
• Once the subject has read any CD in a COI, he/she can only read
  • within the same CD, or
  • another COI

CW-*-Property

A subject $s$ can write to $o$ iff both hold:

1. $s$ can read $o$
2. All $s$ can read are
   • either within $o$'s CD,
   • or sanitized.

---

Design principles

Principles of security design

• Simplicity
• Restriction

Least privilege

• A subject should be given only those information/privileges necessary to complete its task.

Fail-Safe Defaults

• Default action is to deny access unless access privileges are granted explicitly to a subject.
• If action fails, it should undo the actions before it terminates.

Economy of Mechanism

• Keep security mechanism as simple as possible.

Complete Mediation

• Check every access, don't cache or rely on previous permissions.

Open Design

• Security should not depend on secrecy of design or implementation.

Separation of privilege

• Rquire multiple conditions/subjects to grant privilge.

Least Common Mechanism

• Mechanisms/resouces should not be shared.

Psychological Acceptability

• Security mechanisms should not add to the difficulty of accessing resource.

UNIX Security

1. UID, /etc/passwd
2. GID, /etc/group
3. The Superuser

---

Authentication and Identity

Basic concept

• Authentication: to prove an Identity
  • Strong authentication
    • Without transmitting password over Network (then over what?)
    • Or, multi-factor authentication
      • At least two of the following factors.
      • If only password and PIN, it's only one factor.
• Factors
  • What the user know: password, PIN
  • What the user has: ID card, ticket
  • What the user is: figerprint, iris, DNA
• Attach
  • Active: password guessing, cracking password hashes, authentication replay, etc.
  • Passive: password sniffing, etc.

Password Security

• Basic Model (two stages)

  • Registration
  • Login

• Password storage

  • Why not plaintext password
    • The password file could be accessed by insider/outsider
  • Why not the encrypted password
    • Server has to store the key. If the key is lost, same problem as plaintext password
  • Hash (three properties)
    • One-Way
    • Fixed-length output
      • Cannot guess password length
      • Storage efficiency
    • Collision-resistant
      • Weak: Given $x$, to find a 2nd-preimage $x'$ where $x'≠x$ such that $h(x')=h(x)$.
        • Given a password, infeasible to find another password such that their hashes are the same.
      • Strong
        • Most attacks are all about string collision, so passwords are still safe.
        • But dictionary attacks do.

• Dictionary Attacks

  • Two ways
    • Online
      • Compile a dictionary of possible passwords, sorted in likelihood of passwords
      • Try to login with passwords in dictionary
    • Offline
      • Download password file from server
      • Compute hashes of dictionary to try to find a match
  • Time Memory Tradeoff
    • Pre-compute all hashes: faster $O(\log{n})$, but need more space $O(n)$
    • Compute on the fly: slower $O(n)$, but less space $O(1)$
      • $O(n)$ because cannot do binary search
    • In-between: time memory tradeoff method

• Time Memory Tradeoff

  • Assumptions

    • All passwords are three charachters
    • All hashes are also three characters

  • Denote $h^t(abc)=\underbrace{h(h(h\ldots h}_{t}(abc)))$

  • Compute the table ($m\times (t+1)$)

    $abc$	$h(abc)$	$h(h(abc))$	$\ldots$	$\ldots$	$h^{t-1}(h(abc))$	$h^{t}(h(abc))$
    $abd$	$h(abd)$	$h(h(abd))$	$\ldots$	$\ldots$	$h^{t-1}(h(abd))$	$h^{t}(h(abd))$
    $cbd$	$h(cbd)$	$h(h(cbd))$	$\ldots$	$\ldots$	$h^{t-1}(h(cbd))$	$h^{t}(h(cbd))$
    $\ldots$	$\ldots$	$\ldots$	$\ldots$	$\ldots$	$\ldots$	$\ldots$
    $\ldots$	$\ldots$	$\ldots$	$\ldots$	$\ldots$	$\ldots$	$\ldots$
    $foo$	$h(foo)$	$h(h(foo))$	$\ldots$	$\ldots$	$h^{t-1}(h(foo))$	$h^{t}(h(foo))$

  • Suppose we choose $m\times t \geq {26}^{3}=17000$, say $100\times 170$

Challenge-Response

Biometrics

---

Secure Booting

Secure bootstrap architectures and TPM

---

Auditing and Logging

Auditing systems

Auditing in UNIX

Audit log analysis

---

Vulnerability and Defense

Common vulnerabilities

Intrusion detection

---

Securing Network Services

Security in UNIX internet server

Network Security tools in UNIX and Windows

Security protocols

---

Various Topics

Registry security

Embedded and real-time OS security

Cloud computing security

Mobile OS security