14.1 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition The Security Requirements Triad Data confidentiality Privacy Data Integrity

14.1 Silberschatz, Galvin and Gagne ©2009Operating System Concepts – 8th Edition

The Security Requirements Triad

Data confidentiality

Privacy

Data Integrity

System Integrity


Assets

Silberschatz, Galvin and Gagne ©2009Operating System Concepts – 8th Edition,

Chapter 14: Protection


Chapter 14: Protection

Goals of Protection

Principles of Protection

Domain of Protection

Access Matrix

Implementation of Access Matrix

Access Control

Revocation of Access Rights

Capability-Based Systems

Language-Based Protection


Goals of Protection

Prevent accidental or intentional misuse of a system

Accidental

Malicious abuse

Protection problem - ensure that each object is accessed correctly and only by those processes that are allowed to do so.


Goals of Protection

3 aspects to a protection mechanism:

Authentication: User identification Make sure we know who is doing what

Authorization Determination Figure out what the user is and is not allowed to do

Access enforcement Make sure there are no loopholes in the system.


Improving Protection

Guiding principle – principle of least privilege

Programs, users and systems should be given just enough privileges to perform their tasks

Capabilities are an implementation of this idea

Hard to provide foolproof information containment:

A Trojan horse could take page faults and signal to another process

Logging

Record all important actions and uses of privilege in an indelible file.

Correctness proofs

Encryption


User Authentication

Crucial to identify user correctly, as protection systems depend on user ID

User identity most often established through passwords, can be considered a special case of either keys or capabilities

Also can include something user has and /or a user attribute

Passwords must be kept secret

Frequent change of passwords

Use of “non-guessable” passwords

Log all invalid access attempts

Passwords may also either be encrypted or allowed to be used only once


Authentication: Identifying Users How to identify users to the system?

Passwords Very common technique Weak form of prtoection

Smart Cards Electronics embedded in card capable of

providing long passwords or satisfying challenge response queries

Biometrics Who a person IS

– Thumbprint– Retina scan


Passwords: Secrecy

System must keep copy of secret to check against passwords Need to obscure information somehow

Not stored in readable form Mechanism: one-way transformation should be used

Example: UNIX /etc/passwd file passwdone way transform(hash)encrypted passwd System stores only encrypted version, so OK even if someone reads the file! When you type in your password, system compares encrypted version

Problem: Can you trust encryption algorithm? Example: one algorithm thought safe had back door

Governments want back door so they can snoop

Also, security through obscurity doesn’t work

“eagle”


Passwords: How easy to guess? Ways of Compromising Passwords

Password Guessing: Often people use obvious information like birthday, favorite color,

girlfriend’s name, etc…

Dictionary Attack: Work way through dictionary and compare encrypted version of dictionary

words with entries in /etc/passwd

Dumpster Diving: Find pieces of paper with passwords written on them (Also used to get social-security numbers, etc)

Phishing


Passwords: How easy to guess?

Paradox: Short passwords are easy to crack Long ones, people write down!

Technology means we have to use longer passwords UNIX initially required lowercase, 5-letter passwords: total of 265=10million

passwords In 1975, 10ms to check a password1 day to crack In 2005, .01μs to check a password0.1 seconds to crack Even faster today (use multiple processors)

Takes less time to check for all words in the dictionary!

Password checker https://www.microsoft.com/security/pc-security/password-checker.aspx


Passwords: Making harder to crack

How can we make passwords harder to crack? Can’t make it impossible, but can help



Technique 1: Extend everyone’s password with a unique number (stored in password file)

Called “salt”. UNIX uses 12-bit “salt”, making dictionary attacks 4096 times harder

Without salt, would be possible to pre-compute all the words in the dictionary hashed with the UNIX algorithm: would make comparing with /etc/passwd easy!



Technique 2: Require more complex passwords

Make people use at least 8-character passwords with upper-case, lower-case, punctuation, and numbers 708=6x1014=6million seconds=69 [email protected]μs/check

Unfortunately, people still pick common patterns e.g. Capitalize first letter of common word, add one digit



Technique 3: Delay checking of passwords

If attacker doesn’t have access to /etc/passwd, delay every remote login attempt by 1 second

Makes it infeasible for rapid-fire dictionary attack

Technique 4: Assign very long passwords Long passwords or pass-phrases can have more entropy

(randomnessharder to crack)

Give everyone a smart card (or ATM card) to carry around to remember password Requires physical theft to steal password Can require PIN from user before authenticates self

Better: have smartcard generate pseudorandom number Client and server share initial seed Each second/login attempt advances to next random number



Technique 5: “Zero-Knowledge Proof”

Require a series of challenge-response questions Distribute secret algorithm to user

Server presents a number, say “5”; user computes something from the number and returns answer to server

Server never asks same “question” twice

Often performed by smartcard plugged into system


Goals of Protection

3 aspects to a protection mechanism:

Authentication: User identification Make sure we know who is doing what

Authorization Determination Figure out what the user is and is not allowed to do

Access enforcement Make sure there are no loopholes in the system.


Authorization Determination

Must indicate who is allowed do to what with what

ACCESS MATRIX

Two general ways of storing the information

Access Lists

Indicates which users are allowed to perform which operations

Capabilities list

Indicates which files may be accessed in what ways


Domain Structure

Access list : usually a list of pairs

Access-right = <object-name, rights-set>where rights-set is a subset of all valid operations that can be performed on the object.

Domain = set of access-rights

Process operates within a protection domain


Domain Structure

Association between process and domain can be either

STATIC

Fixed

Must provide MOST broad permissions that the process can possible use

May violate the need-to-know principle

DYNAMIC

Modify domain protection rights to time of requirement

Allows domain switching


Domain Structure

A domain can be realized in a variety of ways:

Each user can be a domain

Each process can be a domain

Each procedure can be a domain


Domain Implementation

UNIX

Domain = user-id

Domain switch accomplished via file system.

Each file has associated with it a domain bit (setuid bit).

When file is executed and setuid = on, then user-id is set to owner of the file being executed. When execution completes user-id is reset.

More protective system

Does not allow change of user ID

Uses: daemon process


Access Control

Assume: system knows who the user is

Access request pass through some gatekeeper

USER Process

Resource


Access Matrix

View protection as a matrix (access matrix)

Rows represent domains (unix -> users)

Rows represent user

Users hold ‘ticket’ for each resource

Columns represent objects

Column represents resource

Access(i, j) is the set of operations that a process executing in Domaini can invoke on Objectj


Access Matrix



Each column = Access-control list for one object Defines who can perform what operation.

Domain 1 = Read, WriteDomain 2 = ReadDomain 3 = Read

Each Row = Capability List (like a key)

Fore each domain, what operations allowed on what objects.Object 1 – Read

Object 4 – Read, Write, Execute

Object 5 – Read, Write, Delete, Copy


Use of Access Matrix

If a process in Domain Di tries to do “op” on object Oj, then “op” must be in the access matrix.

Can be expanded to dynamic protection.

Operations to add, delete access rights.

Special access rights:

owner of Oi

copy op from Oi to Oj

control – Di can modify Dj access rights

transfer – switch from domain Di to Dj


Use of Access Matrix (Cont.)

Access matrix design separates mechanism from policy.

Mechanism

Operating system provides access-matrix + rules.

It ensures that the matrix is only manipulated by authorized agents and that rules are strictly enforced.

Policy

User dictates policy.

Who can access what object and in what mode.


Access Matrix of Figure A With Domains as Objects


Access Matrix with Copy Rights


Access Matrix With Owner Rights


Control Rights: Applicable to Domains

Cont

rol

Righ

ts


Control Rights: Applicable to Domains


Access Enforcement

Security kernel

Some part of the system must be responsible for enforcing access control and protecting the authorization and identification information

This portion must be run unprotected. Thus it should be as small and simple as possible

Most systems, like Unix, do not have a security kernel. As a consequence, the systems are not very secure.



Global table

Ordered triples

<domain, object, rights-set>

Access lists for Objects

<domain, rights-set>

Capabilities list for Domains

List of all objects together with the rights for each object.



Lock-Key Mechanism

Compromise

Each object has a list of unique bit patterns ->keys.

A process executing in a domain can access on object only if that domain has a key that matches the object


Access Control

Protection can be applied to non-file resources

Solaris 10 provides role-based access control to implement least privilege

Privilege is right to execute system call or use an option within a system call

Can be assigned to processes

Users assigned roles granting access to privileges and programs


Role-based Access Control in Solaris 10


Revocation of Access Rights

Access List – Delete access rights from access list.

Simple

Immediate

Capability List – Scheme required to locate capability in the system before capability can be revoked.

Reacquisition

Back-pointers (link of all capabilities to that object)

Indirection (global table of capabilities)

Keys


Language-Based Protection

Specification of protection in a programming language allows the high-level description of policies for the allocation and use of resources.

Language implementation can provide software for protection enforcement when automatic hardware-supported checking is unavailable.

Interpret protection specifications to generate calls on whatever protection system is provided by the hardware and the operating system.

The incorporation of protection concepts into programming languages, as a matter of practical design, is in it’s infancy


Protection in Java 2

Protection is handled by the Java Virtual Machine (JVM)

A class is assigned a protection domain when it is loaded by the JVM.

The protection domain indicates what operations the class can (and cannot) perform.

If a library method is invoked that performs a privileged operation, the stack is inspected to ensure the operation can be performed by the library.


Improving Protection

Guiding principle – principle of least privilege

Programs, users and systems should be given just enough privileges to perform their tasks

Capabilities are an implementation of this idea

Hard to provide foolproof information containment:

A Trojan horse could take page faults and signal to another process

Logging

Record all important actions and uses of privilege in an indelible file.

Correctness proofs

Encryption

Silberschatz, Galvin and Gagne ©2009Operating System Concepts – 8th Edition,

End of Chapter 14

Documents

14.1 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition The Security Requirements Triad Data confidentiality Privacy Data Integrity