340 likes | 627 Vues
Internal Protection Mechanisms. 13.1 The Access Control Environment 13.2 Instruction-level Access Control Register and I/O Protection Main Memory Protection 13.3 High-Level Access Control The Access Matrix Model Access Lists and Capability Lists A Comprehensive Example: Client/Server
E N D
Internal Protection Mechanisms 13.1 The Access Control Environment 13.2 Instruction-level Access Control • Register and I/O Protection • Main Memory Protection 13.3 High-Level Access Control • The Access Matrix Model • Access Lists and Capability Lists • A Comprehensive Example: Client/Server • Combining Access Lists and Capability Lists 13.4 Information Flow Control • The Confinement Problem • Hierarchical Information Flow • The Selective Confinement Problem
Access control environment • collection of resources a process may access • hardware or software • static or dynamic • access control enforced at: • instruction level • access to CPU registers, I/O registers, memory • system level • access to files, logical devices
Instruction-level access control • protecting instructions • non-privilegedinstructions: execute in user mode • privilegedinstructions • execute in system (kernel, supervisor) mode • execution in user mode causes trap to OS • transfer to system mode only by special instruction (SVC): sets special CPU bit • protecting CPU registers • general-purpose registers are freely accessible • CPU state registers (program counter, status, timers, interrupts) must be protected • two modes result in a dynamic environment
Instruction-level access control • protecting I/O devices • only system should access controller registers • special I/O instructions: • must be privileged • execute in system mode (as part of drivers) • memorymapped devices: • use memory protection mechanisms to restrict access
Instruction-level access control • protecting main memory • two issues: 1. differentiate between types of access: rwx 000 no access 100 read only 010 write only 110 read and write 001 execute only 101 read and execute 011 write and execute • unrestricted access 2. confine program to assigned areas
Main memory access • systems with static relocation • bounds registers LR pa UR • base register plus length LR pa < LR+L • locks and keys for memory blocks • permit different types of access (rwx)
Main memory access • systems with relocationregisters • similar to static relocation • use limit registers or base/length registers address_map(la) { pa = la + RR; if (!((LR <= pa) && (pa <= UR))) error; return (pa); }
Main memory access • virtual memory: segmentation with paging: • access: type of access permitted to segment (rwx) • len: segment length in bytes • valid: does segment exist • resident: page table or page is resident (page fault) • base: pointer to page table or page in memory
Main memory access • Example: Windows • Page Table: • kernel/user mode access • access type (none, r, rw, x, rx, rwx) • free/reserved/committed • copy on write
Main memory access • sandboxing • restrict program to “sandbox” • prevent Trojan horse attack • guard against erroneous program • memory sandbox: similar to page • divide VM into fix-size blocks: va = (b,w) • program assigned to sandbox s • system checks every address (b,w) for s=b • two sandboxes: • no write into code sandbox (prevent self-modification) • only read/write data sandbox
High-level access control • enforced by software, e.g. file system • access matrix model • resources, subjects, rights R1 R2 R3 R4 S1 rwrwx S2 x rwxrwx S3 rwx r r • implemented as • Analogy: access to conference/restaurant vs theater • access list: R1:(S1,rw)(S3,rwx); R2:(S1,rwx)(S2,r)(S3,r); R3:… • capability list: S1:(R1,rw)(R2,rwx); S2:(R2,x)(R3,rwx)(R4,rwx); S3:…
Access lists vs capability lists • granularity of subjects • AL: • subject=user • owner cannot specify all (future) processes of user • AL is static for user • CL • ticket is given (at runtime) to: user or process • may be propagated dynamically (more flexible) • Analogy: • Restaurant: reservation for John and family (unknown at present; anyone identified as John’s family) • Theater: members also unknown but: John controls propagation at runtime: own family (granularity), others (need restrictions)
Access lists vs capability lists • static vs dynamic environments: • CL • environment varies with each function call • AL • environment changes only when process enters system mode (privileged instructions) • to support user level dynamism: • temporarily change user id while invoking a function • Unix: set-user-id flag on file; during execution, file has its owner’s privileges
Access lists vs capability lists • implementing group access (e.g. wild cards): • reduces list sizes • simplifies authentication • AL • easy to support group access, e.g., default rights for all users to a resource R1 R2 R3 R4 R5 S1 rwrwx S2 x rwxrwxrwx S3 rwx r r * r • access list for R5: (S2,rwx)(*,r) • CL • must find all subjects • future subjects not automatically included
Access lists vs capability lists • Unix: 3 levels: owner, group, other • Multics: • segment in ring i may r/w segment in j, if ij • segment in i may call segment in j, if: • ij; parameters must be copied to ring j • j<i and called segment in j specifies a limit k where ik • linear ordering of all accesses is very limiting
Access lists vs capability lists • adding/removing resources • AL: easy, implement owner right • creator of new resource becomes owner (o-right) R1 R2 R3 R4 R5 S1 rwrwxo S2 x rwxorwxorwxo S3 rwxo r r * r • owner can create/remove/modify resource entry • CL: more difficult • creator of resource get initial capability • this may be propagated to others -- how to control? • owner can remove resource
Access lists vs capability lists • adding/removing subjects R1 R2 R3 R4 R5 S1 rwrwx S2 x rwxrwxrwx S3 rwx r r * r • AL: easy • systemcreates/removes new users • rights granted explicitly or inherited from groups • CL: more difficult • subjects may be individual processes/procedures • creator gets capability for new subject, thus new subject is also a new resource • each new subject gets an emptyCL • capabilities must be propagated to it by other subjects
Access lists vs capability lists • adding/removing rights R1 R2 R3 R4 R5 S1 rwrwxo S2 x rwxorwxorwxo S3 rwxo r x r * r • AL: easy • owner can add/remove/modify subject entries • CL: more difficult • make capabilities unforgeable • control their propagation • allow revocation
Access lists vs capability lists • make capabilities unforgeable • Centralized system: • tagged architecture with privileged instructions • OS maintains CLs, subjects only specify index of capability • Distributed architecture • use large name space (similar to passwords) • use cryptography: • capability = (resource, rights) • system generates random N for resource and issues a ticket: H(resource, rights, N) • subject must present capability + ticket • system computes and compares H to validate cap
Access lists vs capability lists • control capability propagation • implement non-propagation right (e-right) • capability without e-right may not be copied
Access lists vs capability lists • revocation of capabilities • use indirection via alias; destroy alias to revoke
Access lists vs capability lists • using both AL and CL • files • a file is opened using an access list • open file pointer is a capability to read/write • dynamic linking • when segment is accessed for the first time, access is checked; if valid, (s,w) is entered in ST • (s,w) is a form of capability • Kerberos • user is authenticated; if it is allowed to use TGS, it is issued a tg-ticket • ticket is a form of capability
Access lists vs capability lists • client/server example: mutually suspicious systems • Req. 1: user must not steal or damage service • solution: execute-only rights, supported by AL and CL • Req. 2: prevent unauthorized use • AL: rights cannot be propagated by user • CL: need non-propagation mechanisms (e-right)
Access lists vs capability lists • R3: allow owner to revoke access • AL: remove user from list • CL: use alias, or destroy and recreate service with new capability • R4: prevent denial of access • simplest form: destruction of service • prevented by lack of write/delete rights • in general: denial is inability to make progress • hard to distinguish between deliberate slow-down and normal competition for resources • solution: monitor use; report unexpected delays
Access lists vs capability lists • R5: service must access its own resources without giving access to user • AL: implement rights amplification during call (e.g., set-user-id in Unix) • CL: service has its own capability list • R6: service must not be able to access resources not supplied by user (Trojan horse) • AL: difficult • run service with lower privileges than user (e.g., higher ring# in Multics) • copy parameters to the lower group (awkward) • CL: user explicitly passes capabilities to service as parameters
Information flow control • additional requirement: • service must not leak sensitive information • the Confinement Problem • the Selective Confinement Problem
Information flow control • informationflow control ≠access control
Information flow control • Confinement using capabilities: • m-right necessary to modify (enables w-right) • before call
Information flow control • aftercall • m-right removed from service except parameters • Total Confinement only
Information flow control • A hierarchical model • Each resource has a classification level • Each subject has a clearance • Information flows up only • no read up • no write down
Information flow control • Example: confinement problem • during call, service executes at user level • can access user data but not owner data
Information flow control • Selective confinement • Problem: how do we verify what information flows into another object during a computation? • explicit vs implicit flow Z = 1; Y = 2; if (X == 0) Z = Y; • information flows from Y to Z (explicit assignment) • information flows from X to Z (implicit) • by testing Z, we know something about X
Information flow control • use lattice (extension of linear hierarchy) to verify output • Example: program uses Medical and Financial data to produce 2 objects: • one has only Financial (may send to owner) • the other has both (must keep private)
Information flow control • Sneaky signaling: • use covert channels (not reflected in matrix) • Example: • Service: if salary>$100k, open file A, else open file B for exclusive access • Observer: try to open both A and B; depending on which one succeeds, salary information is deduced (leaked) • any observable behavior may signal information • in general, confinement is provably unsolvable