Download Memory Protection

General OS Security:
Memory Protection and Access
Control
CS461/ECE422
1
Reading
• Intel Pentium II Software Developer’s
Manual: Volume 3. Sections 4.5 through 4.8
– http://developer.intel.com/design/processor/man
uals/253668.pdf
2
Outline
• Evolution of OS
• Memory Protection
– Intel Architecture
• Object Access Control
– File access in particular
3
In the Beginning...
• The program owned the machine
– Access hardware directly
• Executives emerged
– Gather common functionality
• Multi-user systems required greater
separation
– Multics, the source of much early OS
development
4
Types of Separation
• Physical
– Use separate physical resources, e.g. Printers,
disk drives
• Temporal
– Time slice different users
• Logical
– Create virtual environment to make it seem that
programs are running independently
• Cryptographic
– Hide data and computation from others
5
Protected Resources
• What resources should be protected?
– Peripherals (e.g. printers)
– Network
– Storage (disk drives, files)
– Memory
• Why protect each of them?
Memory Protection
• Protect Core OS/Maintenance routines from
user program
– Kernel space
– User space
• Hardware support to ensure isolation
7
Memory Fence
Addresses
0
Operating
System
Fence
n
n+1
X
OK
Two problems:
• Flexibility
• Sharing
User
Program
high
8
Fence Registers
Fence
Register
Addresses
0
Operating
System
v.1
n+1
n
n+1
User
Program
high
Fence
Register
Addresses
0
Operating
System
v.2
m+1
m
m+1
User
Program
high
Multiprogramming
Fence
Register
in A
n+1
Fence
Register
in B
m+1
0
n
n+1
m
m+1
high
Operating
System
User
Program
A
User
Program
B
Base & Bound
A’s registers
base n+1
bound m
0
n
n+1
m
m+1
high
Operating
System
User
Program
A
User
Program
B
B’s registers
m+1 base
high bound
Virtual Memory
Fetch 7
A’s registers
Operating
System
7
base n+1
bound m
N+1
+
n+8
n+8
<>
>
Error
<
User
Program
A
User
Program
B
Sharing
A’s registers
base
bound
Operating
System
User
Program
A
Shared
User
Program
B
B’s registers
base
bound
Sharing, Cont’d
Operating
System
User
Program
A
User
Program
B
User
Program
C
Segments
1
Fetch <1,7>
Operating
System
7
+
Seg Base
0
a
1
n+1
Bnd
b
m
n+8
n+8
<>
>
Error
<
User
Program
A
User
Program
B
Split address into
two fields
– <seg, offset>
Each segment has a
base & bound
Segments: Sharing & Protection
Operating
System
Seg Base
0
a
1
n+1
Bnd
b
m
Prot
rwx
rw
{
{
Seg Base
0
m+1
1
n+1
User
Program
A
Shared
User
Program
B
}
}
Bnd Prot
high rwx
m
r
Segment problems
• Accesses off the end of the segment
– Can only be checked at runtime
– Extra check on each memory access
• Numbers are generally used for segment
names to speed up table lookups
– Potential problems for segment sharing
• Need to remap segments when they get too
big for currently mapped location.
17
Paging
• Fixed units of memory mapping
– Page sizes can range from 512 to 8192 bytes
• Two part address: <page #, offset>
• Easier to map fixed units into physical
memory
• Overriding the offset will cause the page # to
change
– Invalid page map should be caught
• Lose logical unity of segments
– May want to protect prog1 segment in a
particular way
18
Paging
19
Paging Segments
• Used by the x86 architecture
– Gives efficiencies of paging architecture with
logical protection continuity of segment
architecture
20
Paging Segments
21
Tagged architectures
• Base/bounds assumes contiguous user
program space.
– Protecting code or data is an all or nothing deal
with the base/bounds technique
• Could add tags to memory units
– Very privileged operation to change tags
– Memory unit could be word or a page
– Used for capability support
– Used by Lisp machines to encode types
• RWX bits on pages for Intel architecture
22
Memory Protection Rings
• More than 2
protection
levels
(why?)
• Originally in
Multics
• In Intel arch
since x386
Privilege Levels
• CPU enforces constraints on memory access and
changes of control between different privilege levels
• Similar in spirit to Bell-LaPadula access control
restrictions
• Hardware enforcement of division between user
mode and kernel mode in operating systems
– Simple malicious code cannot jump into kernel space
Stack Switching
• Automatically performed when calling more
privileged code
– Prevents less privileged code from passing in short
stack and crashing more privileged code
– Each task has a stack defined for each privilege
level
Moving to the Desktop
• Memory protection & rings were used in
MULTICS (‘60s)
• Intel 8086: segmentation, but no memory
protection (1978)
• Intel 80286: protection rings (1982)
• Intel 80386: paging (1986)
• Virtual memory support in Windows - 1995
Limiting Memory Access Type
• The Pentium architecture supports making pages
read/only versus read/write
• A recent development is the Execute Disable Bit
(XD-bit)
– Added in 2001 but only available in systems recently
– Supported by Windows XP SP2
• Similar functionality in AMD Altheon 64
– Called No Execute bit (NX-bit)
– Actually in machines on the market sooner than Intel
Windows Support
• Enabled in Windows XP SP2 as Data Execution
Prevention (DEP)
– Software version if no hardware support
• Check to see if you have the bit
– Control Panel -> System -> Advanced -> DEP tab
Delay to widespread deployment
•
•
•
•
First hardware in 2001
Wait for OS support
Wait for vendors willing to sell
Generally available in 2005
Protecting objects
• Desire to protect logical entities
– Memory
– Files or data sets
– Executing program
– File directory
– A particular data structure like a stack
– Operating system control structures
– Privileged instructions
Access Control Matrix
• Access Control Matrix (ACM) and related
concepts provides very basic abstraction
– Map different systems to a common form for
comparison
– Enables standard proof techniques
– Not directly used in implementation
31
Definitions
• Protection state of system
– Describes current settings, values of system
relevant to protection
• Access control matrix
– Describes protection state precisely
– Matrix describing rights of subjects
– State transitions change elements of matrix
32
Description
objects (entities)
subjects
o1 … om s1 … sn
s1
s2
…
sn
• Subjects S = { s1,…,sn }
• Objects O = { o1,…,om }
• Rights R = { r1,…,rk }
• Entries A[si, oj]  R
• A[si, oj] = { rx, …, ry }
means subject si has rights
rx, …, ry over object oj
33
Example 1
• Processes p, q
• Files f, g
• Rights r, w, x, a (append), o (owner)
f
g
p
q
p
rwo
r
rwxo
w
q
a
ro
r
rwxo
34
Example 2
• Procedures inc_ctr, dec_ctr, manage
• Variable counter
• Rights +, –, call
counter inc_ctr dec_ctr manage
inc_ctr
+
dec_ctr
–
manage
call
call
35
State Transitions
• Change the protection state of system
• |– represents transition
– Xi |–  Xi+1: command  moves system from
state Xi to Xi+1
– Xi |– * Xi+1: a sequence of commands moves
system from state Xi to Xi+1
• Commands often called transformation
procedures
36
Example Transitions
37
Example Composite Transition
38
Practical object access control
• Can slice the logical ACM two ways
– By row: Store with subject
– By column: Store with object
objects (entities)
subjects
o1 … om s1 … sn
s1
s2
…
sn
Directories to manage access
• Slice ACM by user
• Each user keeps a directory
– Entry in directory contains reference to object
(file) and access rights
• Problems
– Large lists
– Revocation
– Object aliases
Directories
Access Control List
• Slice by Object
• Used by Multics and most modern OS's
Unix Access Control
• Three permission octets associated with each
file and directory
– Owner, group, and other
– Read, write, execute
• For each file/directory
– Can specify RWX permissions for one owner, one
group, and one other
43
Windows ACL
44
ACL Scaling
• Groups of users
• Role-Based Access Control
– Users can take on role at a time
• Directory inheritance
• Negative rights
45
Capabilities
• Another attempt to slice by subject
• Capability is an unforgeable token granting access
– How to prevent forging?
• Memory tagging
• store in memory inaccessible to users
• OS proxying
• Subject presents capability when requesting access
• Propagating capabilities
– “Transfer” right passed or not passed with copies of
capabilities
• Capabilities can be easily revoked
Capabilities HW
• Intel iAPX 432 (1981)
– Tried to put even more security enforcement in hardware
– Capabilities and object-oriented
– Segments referenced through Access Descriptors
– Implementation too complex and compiler technology not
sufficiently smart
• Too slow and died on the vine
– http://en.wikipedia.org/wiki/Intel_iAPX_432
• IBM System/38
– From about the same time period
– Also had hardware capabilities support
Key Points
• Separation elements evolved in OS for
safety as much as security
• Memory protections
– Segments and pages and rings
– HW support
• Object access control
– File ACLs
– Capabilities
48