560 likes | 722 Views
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.
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