Ch12 OS Security

Course 12: OS Security
Course 11 review: File Concept

File concept:
Resource for storing information
Contiguous logical address space
User point of view
Interface to information (usually

hierarchical)
OS point of view
File attributes - FCB:
Data structures and allocation

management algorithms
Files contains
Data
Meta-data - FCB
Operating System Concepts 8th Edition
14.2
Name only information kept in

human-readable form
Identifier unique tag (number)

identifies file within file system
Type needed for systems that

support different types
Location pointer to file location on

device
Size current file size
Protection controls who can do

reading, writing, executing
Time, date, and user identification

data for protection, security, and
usage monitoring
Silberschatz, Galvin and Gagne 2008
Course 11 review: File System

Implementation
I/O control - device drivers and interrupt handlers to

transfer information between the main memory and the
disk system. Can be thought of as a translator.
Basic file system - issue generic commands to the
appropriate device driver to read and write physical blocks
on the disk. Each physical block is identified by its
numeric disk address (for example, drive 1, cylinder 73,
track 2, sector 10)
File-organization module knows about files and their
logical blocks, as well as physical blocks. Can translate
logical block addresses to physical block addresses for
the basic file system to transfer.
Logical file system manages metadata information.
Metadata includes all of the file-system structure except
the actual data (or contents of the files). A file-control
block (FCB) contains information about the file, including
ownership, permissions, and location of the file contents.
The logical file system is also responsible for protection
and security
14.3
Course 11 Review File Allocation

Methods
Continuous allocation:
IBM 360
Pros: Fast Sequential

Access, Easy Random
access
Cons: External
Fragmentation/Hard to
grow files
Free holes get
smaller and
smaller
Could compact
space, but that
would be really
expensive
14.4

Methods
Linked allocation:
Pros: Can grow files
dynamically, Free list
same as file
Cons: Bad Sequential
Access (seek between
each block),
Unreliable
(lose block, lose rest
of file)
Serious Con: Bad
random access!!!!
Technique originally
from Alto (First PC,
built at Xerox)
No attempt to
allocate contiguous
blocks
14.5

Methods
Indexed Allocation
System Allocates file
header block to hold
array of pointers big
enough to point to all
blocks
User pre-declares
max file size;
Pros: Can easily
grow up to space
allocated for index
Random
access is fast
Cons: Clumsy to grow
file bigger than table
size
Still lots of
seeks: blocks may be
spread over disk
14.6
Course 11 Review File Allocation Methods

Combined scheme
UNIX 4.1 Pros and cons

Pros:
Simple (more or
less)
Files can easily
expand (up to a
point)
Small files
particularly cheap
and easy
Cons:
Lots of seeks
Very large files

must read many
indirect blocks
(four I/Os per
block
14.7
Chapter 12: OS Security

Security Preventing Misuse
Protection Authorization
Enforcement
14.8
Objectives
Discuss the goals and principles of authentication in a modern
computer system
Discuss the goals and principles of protection in a modern
computer system
Explain how protection domains combined with an access matrix
are used to specify the resources a process may access
14.9
Protection vs Security
Protection: one or more mechanisms for controlling the access of
programs, processes, or users to resources

Page Table Mechanism
File Access Mechanism
Security: use of protection mechanisms to prevent misuse of
resources
Misuse defined with respect to policy
E.g.: prevent exposure of certain sensitive information
E.g.: prevent unauthorized modification/deletion of data
Requires consideration of the external environment within
which the system operates
Most well-constructed system cannot protect information if
user accidentally reveals password
What we hope to gain today
Conceptual understanding of how to make systems secure
Some examples, to illustrate why providing security is really
hard in practice
14.10
14.11

Types of Misuse:
Accidental:
If I delete shell, cant log in to fix it!
Could make it more difficult by asking: do you really want to
delete the shell?
Intentional:
Doesnt help to ask if they want to do it (of course!)
Three Pieces to Security
Authentication: who the user actually is
Authorization: who is allowed to do what
Enforcement: make sure people do only what they are
supposed to do
Loopholes in any carefully constructed system:
Log in as superuser and youve circumvented authentication
Log in as self and can do anything with your resources; for
instance: run program that erases all of your files
Can you trust software to correctly enforce Authentication and
Authorization??
14.12
Authentication: Identifying Users

How to identify users to the system?
Passwords
Shared secret between two parties
Since only user knows password, someone types correct
password must be user typing it
Very common technique
Smart Cards
Electronics embedded in card capable of providing long
passwords or satisfying challenge response queries
May have display to allow reading of password
Or can be plugged in directly; several credit cards now in this
category
Biometrics
Use of one or more intrinsic physical or behavioral traits to
identify someone
Examples: fingerprint reader, palm reader, retinal scan
Becoming quite a bit more common
14.13
Passwords: Secrecy
System must keep copy of secret to check against passwords
What if malicious user gains access to list of passwords?

Need to obscure information somehow
Mechanism: utilize a transformation that is difficult to reverse without
the right key (e.g. encryption)
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 doesnt work
GSM encryption algorithm was secret; accidentally released;
Berkeley grad students cracked in a few hours
14.14
Passwords: How easy to guess?

Ways of Compromising Passwords
Password Guessing:
Often people use obvious information like birthday, favorite color,
girlfriends 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)
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, .01s 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!
14.15
Passwords: Making harder to crack

How can we make passwords harder to crack?
Cant make it impossible, but can help

Technique 1: Extend everyones 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!
Also, way that salt is combined with password designed to frustrate
use of off-the-shelf DES hardware
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 days@0.01s/check
Unfortunately, people still pick common patterns
e.g. Capitalize first letter of common word, add one digit
14.16
Passwords: Making harder to crack

Technique 3: Delay checking of passwords
If attacker doesnt 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
14.17
Protection Authorization
14.18
Goals of Protection/ Principles of

protection
Goals:
Operating system consists of a collection of objects, hardware

or software
Each object has a unique name and can be accessed through

a well-defined set of operations.
Protection problem - ensure that each object is accessed

correctly and only by those processes that are allowed to do
so.
Principles:
Guiding principle principle of least privilege
Programs, users and systems should be given just enough

privileges to perform their tasks
14.19
Domain Structure
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
14.20
Domain Implementation (UNIX)

System consists of 2 domains:
User
Supervisor
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.
14.21
Domain Implementation (MULTICS)

Let Di and Dj be any two domain rings.
If j < I Di Dj
14.22
Access Matrix
View protection as a
matrix (access matrix)

Rows represent domains
Columns represent
objects
Access(i, j) is the set of
operations that a process

executing in Domaini can
invoke on Objectj
14.23
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
14.24
Use of Access Matrix (Cont.)

Access matrix design separates mechanism from policy.
Mechanism
Operating system provides access-matrix + rules.
If 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.
14.25
Access Matrix of Figure A With Domains as Objects
Figure B
14.26
Access Matrix with Copy Rights
14.27
Access Matrix With Owner Rights
14.28
Modified Access Matrix of Figure B
14.29
Implementation of Access Matrix

Global table hard to maintain
ACLs- Each column = Access-control list for one object
Defines who can perform what operation.

Domain 1 = Read, Write
Domain 2 = Read
Domain 3 = Read
CALs - 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
14.30
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
14.31
Role-based Access Control in Solaris 10
14.32
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
Indirection
Keys
14.33
Enforcement
14.34
Enforcement
Enforcer checks passwords, ACLs, etc
Makes sure the only authorized actions take place

Bugs in enforcerthings for malicious users to exploit
In UNIX, superuser can do anything
Because of coarse-grained access control, lots of stuff has to
run as superuser in order to work
If there is a bug in any one of these programs, you lose!
Paradox
Bullet-proof enforcer
Only known way is to make enforcer as small as possible
Easier to make correct, but simple-minded protection model
Fancy protection
Tries to adhere to principle of least privilege
Really hard to get right
Same argument for Java or C++: What do you make private vs
public?
Hard to make sure that code is usable but only necessary
modules are public
Pick something in middle? Get bugs and weak protection!
14.35
State of the World

State of the World in Security
Authentication: Encryption
But almost no one encrypts or has public key identity
Authorization: Access Control
But many systems only provide very coarse-grained access
In UNIX, need to turn off protection to enable sharing
Enforcement: Kernel mode
Hard to write a million line program without bugs
Any bug is a potential security loophole!
14.36
End of Course 12

Ch12 OS Security

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Ch12 OS Security

Uploaded by

Copyright:

Available Formats

Course 12: OS Security

Course 11 review: File Concept

Resource for storing information

Contiguous logical address space

User point of view

Interface to information (usually

File attributes - FCB:

Data structures and allocation

Operating System Concepts 8th Edition

Name only information kept in

Identifier unique tag (number)

Type needed for systems that

Location pointer to file location on

Size current file size

Protection controls who can do

Time, date, and user identification

Course 11 review: File System

I/O control - device drivers and interrupt handlers to

Operating System Concepts 8th Edition

Silberschatz, Galvin and Gagne 2008

Course 11 Review File Allocation

Pros: Fast Sequential

Operating System Concepts 8th Edition

Silberschatz, Galvin and Gagne 2008

Course 11 Review File Allocation

Silberschatz, Galvin and Gagne 2008

Course 11 Review File Allocation

Silberschatz, Galvin and Gagne 2008

Course 11 Review File Allocation Methods

UNIX 4.1 Pros and cons

Very large files

Operating System Concepts 8th Edition

Silberschatz, Galvin and Gagne 2008

Chapter 12: OS Security

Operating System Concepts 8th Edition

Silberschatz, Galvin and Gagne 2008

are used to specify the resources a process may access

Operating System Concepts 8th Edition

Silberschatz, Galvin and Gagne 2008

programs, processes, or users to resources

Silberschatz, Galvin and Gagne 2008

Security Preventing Misuse

Operating System Concepts 8th Edition

Silberschatz, Galvin and Gagne 2008

Security Preventing Misuse

Operating System Concepts 8th Edition

Silberschatz, Galvin and Gagne 2008

Authentication: Identifying Users

Operating System Concepts 8th Edition

Silberschatz, Galvin and Gagne 2008

What if malicious user gains access to list of passwords?

Operating System Concepts 8th Edition

Silberschatz, Galvin and Gagne 2008

Passwords: How easy to guess?

Silberschatz, Galvin and Gagne 2008

Passwords: Making harder to crack

Cant make it impossible, but can help

Operating System Concepts 8th Edition

Silberschatz, Galvin and Gagne 2008

Passwords: Making harder to crack

If attacker doesnt have access to /etc/passwd, delay every remote

Operating System Concepts 8th Edition

Silberschatz, Galvin and Gagne 2008

Operating System Concepts 8th Edition