Internal Protection Mechanisms
13.1 The Access Control Environment
13.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
1
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
2
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
3
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
4
Instruction-level access control
• protecting main memory
– two issues:
1. differentiate between types of access:
rwx
000 no access
100 read only
010 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
Operating Systems
5
Main memory access
• 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
• 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
7
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
8
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
10
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 selfmodification)
– only read/write data sandbox
Operating Systems
11
High-level access control
• enforced by software, e.g. file system
• access matrix model
– resources, subjects, rights
R1
R2
R3
R4
S1 rw
rwx
S2
x
rwx
rwx
S3 rwx
r
r
• implemented as
– access list:
– capability list:
R1:(S1,rw)(S3,rwx);
S1:(R1,rw)(R2,rwx);
R2:(S1,rwx)(S2,r)(S3,r);
S2:(R2,x)(R3,rwx)(R4,rwx);
R3:…
S3:…
• Analogy: access to conference/restaurant vs theater
Operating Systems
12
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
13
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
14
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
R5
S1 rw
rwx
S2
x
rwx
rwx
rwx
S3 rwx
r
r
*
r
– access list for R5: (S2,rwx)(*,r)
• CL
– must find all subjects
– future subjects not automatically included
Operating Systems
15
Access lists vs capability lists
• Unix: 3 levels: owner, group, other
• Multics:
– segment in ring i may r/w
segment in j, if ij
– segment in i may call segment
in j, if:
• ij; parameters must be
copied to ring j
• j<i and called segment in j
specifies a limit k where ik
– linear ordering of all accesses is
very limiting
Operating Systems
16
Access lists vs capability lists
• adding/removing resources
• AL: easy, implement owner right
– creator of new resource becomes owner (o-right)
R1
rw
R2
rwxo
x
r
R3
R4
R5
S1
S2
rwxo
rwxo
rwxo
S3 rwxo
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
17
Access lists vs capability lists
• adding/removing subjects
R1
R2
R3
R4
R5
S1
rw
rwx
S2
x
rwx
rwx
rwx
S3
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
18
Access lists vs capability lists
• adding/removing rights
R1
R2
R3
R4
R5
S1 rw
rwxo
S2
x
rwxo
rwxo
rwxo
S3 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
19
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
20
Access lists vs capability lists
• control capability propagation
– implement non-propagation right (e-right)
– capability without e-right may not be copied
Operating Systems
21
Access lists vs capability lists
• revocation of capabilities
– use indirection via alias; destroy alias to revoke
Operating Systems
22
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
24
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
25
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
26
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
27
Information flow control
• additional requirement:
– service must not leak sensitive information
• the Confinement Problem
• the Selective Confinement Problem
Operating Systems
28
Information flow control
• information flow control ≠ access control
Operating Systems
29
Information flow control
• Confinement using capabilities:
– m-right necessary to modify (enables w-right)
• before call
Operating Systems
30
Information flow control
• after call
– m-right removed from service except parameters
– Total Confinement only
Operating Systems
31
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
32
Information flow control
• Example: confinement problem
– during call, service executes at user level
– can access user data but not owner data
Operating Systems
33
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
35
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)
Operating Systems
36
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