General OS Security: Memory Protection and Access Control

1
General OS SecurityMemory Protection and Access
Control

• CS461/ECE422
• Fall 2007

2
Reading

• Security in Computing 4.1-4.4
• Intel Pentium II Software Developers Manual
  Volume 3. Sections 4.5 through 4.8
• http//developer.intel.com/design/processor/manual
  s/253668.pdf

3
Outline

• Evolution of OS
• Memory Protection
• Intel Architecture
• Object Access Control
• File access in particular

4
In the Beginning...

• The program owned the machine
• Access all power of the hardware
• Could really mess things up
• Executives emerged
• Gather common functionality
• Multi-user systems required greater separation
• Multics, the source of much early OS development

5
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

6
Memory Protection

• Protect Core OS/Maintenance routines from user
  program
• Kernel space
• User space
• Relocation
• If kernel program size varies, don't need to
  rewrite User program

7
Fence Registers
8
Base/Bounds Registers

• Fence register prevents User program from
  accessing data too low.
• What about addresses too high?
• Add a bounds register
• What about user program overwriting own program?
• A pair of registers for both program and data
  space

9
Base/Bounds Register
10
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

11
Segments

• Virtual memory
• User programs refers to name and offset instead
  of direct address
• ltname, offsetgt, e.g., ltfred, 46gt
• OS translates from current segment mapping to
  real physical address at runtime
• All memory accesses pass through OS
• Hardware assists
• Freedom to layout program segments independently
• Can later remap to different physical location

12
Segments
13
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.

14
Paging

• Fixed units of memory mapping
• Page sizes can range from 512 to 8192 bytes
• Two part address ltpage , offsetgt
• 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

15
Paging
16
Paging Segments

• Used by the x86 architecture
• Gives efficiencies of paging architecture with
  logical protection continuity of segment
  architecture

17
Paging Segments
18
Memory Protection Rings

• Originally in Multics
• In Intel arch since x386

19
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

20
Data Access Rules

• Access allowed if
• CPL lt DPL and RPL lt DPL

21
Data Access Rules

• Three players
• Code segment has a current privilege level CPL
• Operand segment selector has a requested
  privilege level RPL
• Data Segment Descriptor for each memory includes
  a data privilege level DPL
• Segment is loaded if CPL lt DPL and RPL lt DPL
• i.e. both CPL and RPL are from more privileged
  rings

22
Data Access Examples
23
Direct Control Transfers

• For non-conforming code (the common case)
• RPL lt CPL CPL DPL
• Can only directly jump to code at same privilege
  level

24
Calling Through Gates
DLP
25
Call Gate Access Rules

• For Call
• CPL lt CG DPL
• RPL lt CG DPL
• Dst CS DPL lt CPL
• Same for JMP but
• Dst CS DPL CPL

26
Call Gate Examples
27
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

28
Hardware Rings

• Only most basic features generally used
• 2 rings
• Installed base
• Time to adoption
• Must wait for widespread system code, e.g.
  Windows NT

29
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

30
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 -gt System -gt Advanced -gt DEP tab

31
Delay to widespread deployment

• First hardware in 2001
• Wait for OS support
• Wait for vendors willing to sell
• Generally available in 2005

32
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

33
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

34
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

35
Description

• Subjects S s1,,sn
• Objects O o1,,om
• Rights R r1,,rk
• Entries Asi, oj ??R
• Asi, oj rx, , ry means subject si has
  rights rx, , ry over object oj

36
Example 1

• Processes p, q
• Files f, g
• Rights r, w, x, a, o
• f g p
  q
• p rwo r rwxo w
• q a ro r
  rwxo

37
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 call

38
State Transitions

• Change the protection state of system
• represents transition
• Xi ? Xi1 command ? moves system from state
  Xi to Xi1
• Xi Xi1 a sequence of commands moves system
  from state Xi to Xi1
• Commands often called transformation procedures

39
Example Transitions
40
Example Composite Transition
41
Practical object access control

• Can slice the logical ACM two ways
• By row Store with subject
• By column Store with object

42
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

43
Directories
44
Access Control List

• Slice by Object
• Used by Multics and most modern OS's

45
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

46
Windows ACL
47
ACL Scaling

• Groups of users
• Role Base Access Control
• Users can take on role at a time
• Directory inheritance
• Negative rights

48
Capabilities

• Another attempt to slice by subject
• Capability is an unforgeable token granting
  access
• How to prevent forging?
• Memory tagging
• OS proxying
• Subject presents capability when requesting
  access
• Propagating capabilities
• Capabilities can be easily revoked

49
Capabilities HW

• Intel iAPX 432 (mid 70s)
• Tried to put even more security enforcement in
  hardware
• Capabilities and object-oriented
• 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

50
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