Operating Systems 1

Internal Protection Mechanisms13.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

Operating Systems 2

Access control environment• collection of resources 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

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 causes trap 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 a dynamic environment

Operating Systems 4

Instruction-level access control• protecting I/O devices

– only system should access controller registers

– special I/O instructions:

• must be privileged

• execute in system mode (as part of drivers)

– memory mapped devices:

• use memory protection mechanisms to restrict access

Operating Systems 5

Instruction-level access control• protecting main memory

– two issues:1. differentiate between types of access:

rwx000 no access 100 read only 010 write only110 read and write 001 execute only101 read and execute 011 write and execute 111unrestricted access

2. confine program to assigned areas

• systems with static relocation– bounds registers

LR pa UR

– base register plus length

LR pa < LR+L– locks and keys for memory blocks

• permit different types of access (rwx)

Operating Systems 6

Main memory access

Operating Systems 7

Main memory access• systems with relocation registers

– similar to static relocation• use limit registers or base/length registers

address_map(la) { pa = la + RR; if (!((LR <= pa) && (pa <= UR))) error; return (pa); }

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

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

Operating Systems 11

Main memory access• sandboxing

– restrict program to “sandbox”• prevent Trojan horse attack• guard against erroneous 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 into code sandbox (prevent self-modification)

– only read/write data sandbox

Operating Systems 12

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

– resources, subjects, rights

R1 R2 R3 R4S1 rw rwxS2 x rwx rwxS3 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:…

Operating Systems 13

Access lists vs capability lists• granularity of subjects– AL:

• subject=user• owner cannot specify all

(future) processes of user• AL is static 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 at present; anyone identified as John’s family)

– Theater: members also unknown but: John controls propagation at runtime: own family (granularity), others (need restrictions)

Operating Systems 14

Access lists vs capability lists• static vs dynamic environments:

• CL – environment varies with each function call

• AL– environment changes only when process enters system

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, file has its owner’s privileges

Operating Systems 15

Access lists vs capability lists• implementing group access (e.g. wild cards):

– reduces list sizes– simplifies authentication

• AL– easy to support group access, e.g., default rights for all

users to a resource R1 R2 R3 R4 R5S1 rw rwxS2 x rwx rwx rwxS3 rwx r r* r

– access list for R5: (S2,rwx)(*,r)• CL

– must find all subjects– future subjects not automatically included

Operating Systems 16

Access lists vs capability lists• Unix: 3 levels: owner, group, other• Multics:– segment in ring i may r/w

segment in j, if ij– segment in i may call segment

in j, if: • ij; parameters must be

copied to ring j• j<i and called segment in j

specifies a limit k where ik– linear ordering of all accesses is

very limiting

Operating Systems 17

Access lists vs capability lists• adding/removing resources

• AL: easy, implement owner right– creator of new resource becomes owner (o-right)

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

– owner can create/remove/modify resource entry

• CL: more difficult– creator of resource get initial capability

• this may be propagated to others -- how to control?– owner can remove resource

Operating Systems 18

Access lists vs capability lists• adding/removing subjects

R1 R2 R3 R4 R5S1 rw rwxS2 x rwx rwx rwxS3 rwx r r* r

• AL: easy– system creates/removes new users– rights granted explicitly or inherited from groups

• CL: more difficult– subjects may be individual processes/procedures– creator gets capability for new subject, thus new

subject is also a new resource– each new subject gets an empty CL– capabilities must be propagated to it by other subjects

Operating Systems 19

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: easy– owner can add/remove/modify subject entries

• CL: more difficult• make capabilities unforgeable• control their propagation• allow revocation

Operating Systems 20

Access lists vs capability lists• make capabilities unforgeable

– Centralized system:• tagged architecture with privileged instructions• OS maintains CLs, subjects only specify index of

capability

– Distributed architecture• use large name space (similar to passwords)• use cryptography:

– 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

Operating Systems 21

Access lists vs capability lists• control capability propagation

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

Operating Systems 22

Access lists vs capability lists• revocation of capabilities

– use indirection via alias; destroy alias to revoke

Operating Systems 24

Access lists vs capability lists• using both AL and CL• files

– a file is opened using an access list– open file pointer is a capability to read/write

• dynamic linking– when segment is accessed for the first time, access is

checked; 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 is

issued a tg-ticket– ticket is a form of capability

Operating Systems 25

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

• Req. 1: user must not steal or damage service– solution: execute-only rights, supported by AL and CL

• Req. 2: prevent unauthorized use– AL: rights cannot be propagated by user– CL: need non-propagation mechanisms (e-right)

Operating Systems 26

Access lists vs capability lists• R3: allow owner to revoke access

– AL: remove user from list– CL: use alias, or destroy and recreate service with new

capability

• R4: prevent denial 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 between deliberate slow-down and normal competition for resources

• solution: monitor use; report unexpected delays

Operating Systems 27

Access lists vs capability lists• R5: service must access 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 access resources 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

Operating Systems 28

Information flow control• additional requirement:

– service must not leak sensitive information

• the Confinement Problem• the Selective Confinement Problem

Operating Systems 29

Information flow control• information flow control ≠ access control

Operating Systems 30

Information flow control• Confinement using capabilities:

– m-right necessary to modify (enables w-right)• before call

Operating Systems 31

Information flow control• after call

– m-right removed from service except parameters

– Total Confinement only

Operating Systems 32

Information flow control• A hierarchical model

– Each resource has a classification level

– Each subject has a clearance

– Information flows up only• no read up• no write down

Operating Systems 33

Information flow control• Example: confinement problem

– during call, service executes at user level– can access user data but not owner data

Operating Systems 35

Information flow control• Selective confinement

• Problem: how do we verify what 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

Operating Systems 36

Information flow control• use lattice (extension of linear hierarchy) to verify output• Example: program uses Medical and Financial data to

produce 2 objects: – one has only Financial (may send to owner)– the other has both (must keep private)

Information flow control• Sneaky signaling:

– use covert 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)

– any observable behavior may signal information

– in general, confinement is provably unsolvable

Operating Systems 37