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

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

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

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

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

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

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

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

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

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 Johns 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 owners 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 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

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

Exercise
Consider five objects A, B, D1, D2, D3 in a capabilitybased system.
Show the graphical representation such that:
A can call B
B can read and write data from/to D1
B can give its capability for D1 to another object D2
A can read and write the capability list of D1
A can read data from D3
B can read and write data from/to D3
Answer the following questions:
Can data from D3 ever get into D1?
Can data from D3 ever get into D2?
Can data from D1 ever get into A?
Can data from D2 ever get into A?
Operating Systems

23

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

Exercise
Assume subjects A, B and resources X, Y
a. 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

Operating Systems

34

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