General OS Security: Memory Protection and Access Control CS461/ECE422
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
Outline Evolution of OS Memory Protection Intel Architecture Object Access Control File access in particular
In the Beginning... The program owned the machine Executives emerged Access hardware directly Executives emerged Gather common functionality Multi-user systems required greater separation Multics, the source of much early OS development Protect programs from each other
Types of Separation Physical Temporal Logical Cryptographic 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 These were defined in the ‘60s, actually Which is most efficient? Why? Which is most secure? Why? Focus on logical from now on
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 Why is hardware needed? Have you heard of COREWARS?
Memory Fence Addresses Operating System Two problems: Flexibility n Operating System Two problems: Flexibility Sharing n X Fence User Program n+1 Can the OS access the user program? Yes, one-way barrier OK high
Fence Registers Addresses Addresses Operating System Operating System v.2 User Program m m+1 Addresses high Operating System v.1 Fence Register Fence Register n+1 n User Program n+1 high
Multiprogramming Operating System n+1 m+1 n User Program A n+1 m m+1 Operating System Fence Register in A n+1 in B m+1 n User Program A n+1 m Can we use the fence register to protect A from B? Can we protect B from A? No. m+1 User Program B high
Base & Bound Operating System n m+1 base base n+1 User Program A n+1 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
Virtual Memory + < <> > Fetch 7 Operating System N+1 base A’s registers + 7 N+1 base n+1 User Program A < n+8 bound m <> n+8 User Program B Error >
Sharing Operating System base User Program bound A Shared User Program A’s registers B’s registers Shared Operating System User Program A Can A & B share data? Incidentally, why might they want to do this? User Program B
Sharing, Cont’d Operating System User Program A User Program B Can A, B, and C all share some data? User Program C
Segments + < <> > Split address into two fields <seg, offset> Each segment has a base & bound 1 Fetch <1,7> Operating System + 7 User Program A < n+8 <> n+8 Seg Base Bnd a b 1 n+1 m User Program B Error >
Segments: Sharing & Protection Operating System Seg Base Bnd Prot a b rwx 1 n+1 m rw Seg Base Bnd Prot m+1 high rwx 1 n+1 m r { 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
Paging Segments Used by the x86 architecture Gives efficiencies of paging architecture with logical protection continuity of segment architecture
Paging Segments
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
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 Why would desktop software need memory protection?
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 Break?
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 Access control matrix 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
Description objects (entities) 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 objects (entities) subjects s1 s2 … sn o1 … om s1 … sn
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 counter inc_ctr dec_ctr manage inc_ctr + dec_ctr – manage 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
Example Transitions
Example Composite Transition
Practical object access control Can slice the logical ACM two ways By row: Store with subject By column: Store with object objects (entities) subjects s1 s2 … sn o1 … om s1 … 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
Windows ACL
ACL Scaling Groups of users Role-Based Access Control Users can take on role at a time Directory inheritance Negative rights
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) IBM System/38 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