Ch12 OS Security

Course 12: OS Security

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

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

Data structures and allocation

management algorithms

Files contains

Data

Meta-data - FCB

File attributes - FCB:

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


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


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 reallyexpensive



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



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


Course 11 Review – File Allocation Methods

Combined schemeUNIX 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


Chapter 12: OS Security

Security – Preventing Misuse

Protection – Authorization

Enforcement


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


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





Types of Misuse: Accidental:

If I delete shell, can’t log in to fix it! Could make it more difficult by asking: “do you really want to

delete the shell?” Intentional:

Doesn’t 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 you’ve 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??


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


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 doesn’t work

GSM encryption algorithm was secret; accidentally released; Berkeley grad students cracked in a few hours


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)

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!


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!

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 [email protected]μs/check

Unfortunately, people still pick common patterns

e.g. Capitalize first letter of common word, add one digit


Passwords: Making harder to crack

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


Protection – Authorization


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


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


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.


Domain Implementation (MULTICS)

Let Di and Dj be any two domain rings.

If j < I Di Dj


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


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.

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.


Access Matrix of Figure A With Domains as Objects

Figure B


Access Matrix with Copy Rights


Access Matrix With Owner Rights


Modified Access Matrix of Figure B


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, WriteDomain 2 = ReadDomain 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


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

Indirection

Keys


Enforcement


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!


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!

End of Course 12

Date post:	24-Dec-2015
Category:	Documents
Upload:	mmmaya
View:	231 times
Download:	2 times

Ch12 OS Security

Documents