ch13 of awesome please computing system

8/10/2019 ch13 of awesome please computing system

1/37

Operating Systems 1

Internal Protection Mechanisms

13.1 The Access Control Environment13.2 Instruction-level Access Control

Register and I/O Protection

Main Memory Protection

13.3 High-Level Access Control

The Access Matrix Model

Access Lists and Capability Lists

A Comprehensive Example: Client/Server

Combining Access Lists and Capability Lists

13.4 Information Flow Control

The Confinement Problem

Hierarchical Information Flow

The Selective Confinement Problem


2/37

Operating Systems 2

Access control environment

collection ofresources a process may access hardware or software

static or dynamic

access control enforced at:

instruction level

access to CPU registers, I/O registers, memory

system level

access to files, logical devices


3/37

Operating Systems 3

Instruction-level access control protecting instructions

non-privileged instructions: execute in user mode

privileged instructions

execute in system (kernel, supervisor) mode

execution in user mode causestrap to OS

transfer to system mode only by special instruction(SVC): sets special CPU bit

protecting CPU registers

general-purpose registers are freely accessible

CPU state registers (program counter, status, timers,

interrupts) must be protected two modes result in adynamic environment


4/37

Operating Systems 4

Instruction-level access control

protecting I/O devices only system should accesscontroller registers

specialI/O instructions:

must be privileged

execute in system mode (as part of drivers)memory mapped devices:

use memory protection mechanisms to restrictaccess


5/37

Operating Systems 5

Instruction-level access control protecting main memory

two issues:

1. differentiate betweentypes of access:

rwx

000 no access

100 read only010 write only

110 read and write

001 execute only

101 read and execute

011 write and execute

111unrestricted access

2.confine program to assigned areas


6/37

systems withstatic relocationbounds registers

LR pa UR

base register pluslength

LR pa < LR+L

locks and keys for memory blocks

permit different types of access (rwx)

Operating Systems 6

Main memory access


7/37

Operating Systems 7

Main memory access

systems withrelocation registers similar to static relocation

use limit registers or base/length registers

address_map(la) {

pa = la + RR;

if (!((LR


8/37

Operating Systems 8

Main memory access virtual memory:segmentation with paging:

access: type of access permitted to segment (rwx) len: segment length in bytes

valid: does segment exist

resident: page table or page is resident (page fault)

base: pointer to page table or page in memory


9/37

Exercise

Assume segmentation with paging va = (s,p,w), |s| = 5, |p| = 7, |w| = 9

Assume:

there are 5 segments with the following lengths:

50, 515, 2048, 1200, 2049

Why are the following address invalid?

a. (9, 0, 0)

b. (4, 5, 6)

c. (1, 1, 15)

Operating Systems 9


10/37

Operating Systems 10

Main memory access

Example: Windows Page Table:

kernel/user mode access

access type (none, r, rw, x, rx, rwx)

free/reserved/committed

copy on write


11/37


Main memory access sandboxing

restrict program to sandbox

preventTrojan horse attack

guard againsterroneous program

memory sandbox: similar to page

divide VM into fix-size blocks: va = (b,w) program assigned to sandbox s

system checks every address (b,w) for s=b

two sandboxes:

no write intocode sandbox (prevent self-

modification)

only read/writedata sandbox


12/37


High-level access control enforced by software, e.g. file system

access matrix modelresources, subjects, rights

R1 R2 R3 R4

S1 rw rwx

S2 x rwx rwx

S3 rwx r r

implemented as

Analogy: access to conference/restaurant vs theater

access list:

R1:(S1,rw)(S3,rwx);

R2:(S1,rwx)(S2,r)(S3,r);R3:

capability list:

S1:(R1,rw)(R2,rwx);

S2:(R2,x)(R3,rwx)(R4,rwx);S3:


13/37


Access lists vs capability lists granularity of subjects

AL: subject=user

owner cannot specify all

(future) processes of user

AL isstatic for user

CL

ticket is given (at runtime) to:user or process

may be propagated

dynamically (more flexible)

Analogy:

Restaurant: reservation for John and family (unknown atpresent; anyone identified as Johns family)

Theater: members also unknown but: John controls propagation

at runtime: own family (granularity), others (need restrictions)


14/37


Access lists vs capability lists static vs dynamic environments:

CL

environmentvaries with each function call

AL

environment changes only when process enterssystem

mode (privileged instructions) to support user level dynamism:

temporarily change user id while invoking a

function

Unix: set-user-id flag on file; during execution, filehas its owners privileges


15/37


16/37


Access lists vs capability lists Unix: 3 levels: owner, group, other

Multics:

segment in ring i mayr/w

segment in j, if ij

segment in i maycall segment

in j, if: ij; parameters must be

copied to ring j

j


17/37


Access lists vs capability lists adding/removing resources

AL: easy, implementowner right

creator of new resource becomes owner (o-right)

R1 R2 R3 R4 R5S1 rw rwxo

S2 x rwxo rwxo rwxoS3 rwxo r r* r

owner cancreate/remove/modify resource entry

CL: more difficult

creator of resource getinitial capability this may bepropagated to others -- how to control?

owner canremove resource


18/37


19/37


Access lists vs capability lists adding/removing rights

R1 R2 R3 R4 R5S1 rw rwxoS2 x rwxo rwxo rwxoS3 rwxo r x r* r

AL: easyowner can add/remove/modify subject entries

CL: more difficult

make capabilitiesunforgeable

control theirpropagation allowrevocation


20/37


Access lists vs capability lists make capabilitiesunforgeable

Centralized system:

tagged architecture with privileged instructions

OS maintains CLs, subjects only specifyindex of

capability

Distributed architecture uselarge name space (similar to passwords)

usecryptography:

capability = (resource, rights)

system generates random N for resource and issues a

ticket: H(resource, rights, N)subject must present capability + ticket

system computes and compares H to validate cap


21/37


Access lists vs capability lists control capabilitypropagation

implement non-propagation right (e-right) capability without e-right may not be copied


22/37


Access lists vs capability lists revocation of capabilities

use indirection viaalias; destroy alias to revoke


23/37


24/37


Access lists vs capability lists using both AL and CL

files

a file isopened using an access list

open file pointer is a capability toread/write

dynamic linking

when segment is accessed for thefirst time, access ischecked; if valid, (s,w) is entered in ST

(s,w) is a form of capability

Kerberos

user is authenticated; if it is allowed to use TGS, it isissued a tg-ticket

ticket is a form of capability


25/37


Access lists vs capability lists client/server example:mutually suspicious systems

Req. 1: user must notsteal ordamage service

solution:execute-only rights, supported by AL and CL

Req. 2: prevent unauthorizeduse

AL: rights cannot be propagated by user CL: need non-propagation mechanisms (e-right)


26/37


Access lists vs capability lists R3: allow owner torevoke access

AL: remove user from list

CL: use alias, or destroy and recreate service with new

capability

R4: preventdenial of access

simplest form:destruction of service

prevented by lack of write/delete rights

in general: denial is inability to make progress

hard to distinguish betweendeliberate slow-down

and normal competition for resources solution:monitor use; report unexpected delays


27/37


Access lists vs capability lists R5: service mustaccess its own resources without giving

access to user AL: implement rights amplification during call (e.g.,

set-user-id in Unix)

CL: service has its own capability list

R6: service must not be able to accessresources not

supplied by user (Trojan horse)

AL: difficult

run service with lower privileges than user (e.g.,

higher ring# in Multics)

copy parameters to the lower group (awkward) CL: user explicitly passes capabilities to service as

parameters


28/37


Information flow control

additional requirement: service must notleak sensitive information

theConfinement Problem

theSelective Confinement Problem


29/37


Information flow control information flow control access control


30/37


31/37


Information flow control after call

m-right removed from service except parameters

Total Confinement only


32/37


Information flow control

Ahierarchical model Each resource has a

classification level

Each subject has a

clearance

Informationflows up

only

no read up

no write down


33/37


34/37

Exercise

Assume subjects A, B and resources X, Ya. Assign clearances and classification levels such that:

A can write only X

B can write X, Y

b. Can this be changed such that B can write only Y?

c. What can A and B read?

d. Modify such that:

1. A cannot read X

2. A cannot read X and B cannot read Y

3. A, B cannot read anything



35/37


Information flow control Selective confinement

Problem: how do we verifywhat information flows into

another object during a computation?

explicit vs implicit flow

Z = 1;

Y = 2;if (X == 0) Z = Y;

information flows from Y to Z (explicit assignment)

information flows from X to Z (implicit)

by testing Z, we know something about X


36/37


Information flow control uselattice (extension of linear hierarchy) toverify output

Example

: program uses Medical and Financial data toproduce 2 objects:

one hasonly Financial (may send to owner)

the other hasboth (must keep private)


37/37

Information flow control Sneaky signaling:

usecovert channels (not reflected in matrix)

Example:

Service: if salary>$100k, open file A, else open file B

for exclusive access

Observer: try to open both A and B; depending on

which one succeeds, salary information is deduced

(leaked)

anyobservable behavior may signal information

in general, confinement is provablyunsolvable


Documents

ch13 of awesome please computing system