1 / 34

Internal Protection Mechanisms

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

becca
Télécharger la présentation

Internal Protection Mechanisms

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. 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

  2. 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

  3. 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

  4. 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

  5. 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

  6. 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)

  7. 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); }

  8. 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

  9. 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

  10. 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

  11. 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:…

  12. 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)

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

  14. 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

  15. Access lists vs capability lists • Unix: 3 levels: owner, group, other • Multics: • segment in ring i may r/w segment in j, if ij • segment in i may call segment in j, if: • ij; parameters must be copied to ring j • j<i and called segment in j specifies a limit k where ik • linear ordering of all accesses is very limiting

  16. 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

  17. 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

  18. 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

  19. 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

  20. Access lists vs capability lists • control capability propagation • implement non-propagation right (e-right) • capability without e-right may not be copied

  21. Access lists vs capability lists • revocation of capabilities • use indirection via alias; destroy alias to revoke

  22. 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

  23. 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)

  24. 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

  25. 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

  26. Information flow control • additional requirement: • service must not leak sensitive information • the Confinement Problem • the Selective Confinement Problem

  27. Information flow control • informationflow control ≠access control

  28. Information flow control • Confinement using capabilities: • m-right necessary to modify (enables w-right) • before call

  29. Information flow control • aftercall • m-right removed from service except parameters • Total Confinement only

  30. 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

  31. Information flow control • Example: confinement problem • during call, service executes at user level • can access user data but not owner data

  32. 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

  33. 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)

  34. 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

More Related