560 likes | 733 Vues
This document provides a comprehensive overview of memory protection and access control in operating systems, focusing on the evolution of OS architectures, specifically Intel's architecture, and the mechanisms implemented for security. It covers essential topics such as memory protection techniques, physical, temporal, logical, and cryptographic separation of resources, and details on paging and segmentation used in systems. Additionally, it discusses the roles of privilege levels and data access rules impacting secure operations within multi-user environments.
E N D
CS461/ECE422 Spring 2008 General OS Security:Memory Protection and Access Control
Reading • Security in Computing – 4.1-4.4 • Intel Pentium II Software Developer’s Manual: Volume 3. Sections 4.5 through 4.8 • http://developer.intel.com/design/processor/manuals/253668.pdf
Outline • Evolution of OS • Memory Protection • Intel Architecture • Object Access Control • File access in particular
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
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
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
X OK Memory Fence Addresses 0 Operating System • Two problems: • Flexibility • Sharing n Fence User Program n+1 high
Addresses 0 Operating System v.2 m+1 m User Program m+1 high Fence Registers Addresses 0 Operating System v.1 Fence Register Fence Register n+1 n User Program n+1 high
Fence Register in A n+1 Fence Register in B m+1 Multiprogramming 0 Operating System n User Program A n+1 m m+1 User Program B high
Base & Bound 0 Operating System B’s registers A’s registers n m+1 base base n+1 User Program A n+1 high bound bound m m m+1 User Program B high
7 + n+8 n+8 < <> > Error Virtual Memory Fetch 7 Operating System A’s registers N+1 base n+1 User Program A bound m User Program B
B’s registers A’s registers base base bound bound Shared Sharing Operating System User Program A User Program B
Sharing, Cont’d Operating System User Program A User Program B User Program C
1 7 + n+8 n+8 < <> > Error Segments Split address into two fields • <seg, offset> Each segment has a base & bound Fetch <1,7> Operating System User Program A User Program B
Segments: Sharing & Protection Operating System { User Program A { Shared } User Program B }
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.
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
Paging Segments • Used by the x86 architecture • Gives efficiencies of paging architecture with logical protection continuity of segment architecture
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
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
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 <= DPL and RPL <= DPL • i.e. both CPL and RPL are from more privileged rings
Data Access Rules • Access allowed if • CPL <= DPL and RPL <= DPL
Direct Control Transfers • For non-conforming code (the common case) • RPL <= DPL && CPL == DPL • Can only directly jump to code at same privilege level
Call Gate Access Rules • For Call • CPL <= CG DPL • RPL <= CG DPL • Dst CS DPL <= CPL • Same for JMP but • Dst CS DPL == CPL
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
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
objects (entities) o1 … oms1 … sn s1 s2 … sn subjects Description • 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
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
Example 2 • Procedures inc_ctr, dec_ctr, manage • Variable counter • Rights +, –, call counterinc_ctr dec_ctr manage inc_ctr + dec_ctr – manage call call call
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
objects (entities) o1 … oms1 … sn s1 s2 … sn subjects Practical object access control • Can slice the logical ACM two ways • By row: Store with subject • By column: Store with object
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
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