13-Internal Protection Mechanisms

1 .Operating Systems 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 .Operating Systems 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 .Operating Systems 3 Instruction-level access control protecting instructions non-privileged instructions: execute in user mode privileged instructions 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 .Operating Systems 4 Instruction-level access control p rotecting I/O devices only system should access controller registers special I/O instructions : must be privileged execute in system mode (as part of drivers) memory mapped devices: use memory protection mechanisms to restrict access

5 .Operating Systems 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 .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 ) Operating Systems 6 Main memory access

7 .Operating Systems 7 Main memory access systems with relocation registers 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 .Operating Systems 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 .Exercise Assume segmentation with paging va = ( s,p,w ), |s| = 5, |p| = 7, | w| = 9 Assume: there are 5 segments with the following lengths : 50 , 515, 2048, 1200, 2049 Why are the following address invalid? ( 9, 0, 0) ( 4, 5, 6) ( 1, 1, 15) Operating Systems 9

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

11 .Operating Systems 11 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

12 .Operating Systems 12 High-level access control enforced by software, e.g. file system access matrix model resources, subjects, rights R1 R2 R3 R4 S1 rw rwx S2 x rwx rwx 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:…

13 .Operating Systems 13 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)

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

15 .Operating Systems 15 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 rw rwx S2 x rwx rwx rwx S3 rwx r r * r access list for R5: (S2,rwx)(*,r) CL must find all subjects future subjects not automatically included

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

17 .Operating Systems 17 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 rw rwxo S2 x rwxo rwxo rwxo 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

18 .Operating Systems 18 Access lists vs capability lists adding/removing subjects R1 R2 R3 R4 R5 S1 rw rwx S2 x rwx rwx rwx S3 rwx r r * r AL: easy system creates/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 empty CL capabilities must be propagated to it by other subjects

19 .Operating Systems 19 Access lists vs capability lists adding/removing rights R1 R2 R3 R4 R5 S1 rw rwxo S2 x r wx o rwxo rwxo 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

20 .Operating Systems 20 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 ) u se cryptography : capability = (resource, rights) system generates random N for resource and issues a ticket: H(resource , rights, N) s ubject must present capability + ticket system computes and compares H to validate cap

21 .Operating Systems 21 Access lists vs capability lists control capability propagation implement non-propagation right ( e-right ) capability without e-right may not be copied

22 .Operating Systems 22 Access lists vs capability lists revocation of capabilities use indirection via alias ; destroy alias to revoke

23 .Exercise Consider five objects A, B, D1, D2, D3 in a capability-based system. Show the graphical representation such that: A can call B B can read and write data from/to D1 B can give its capability for D1 to another object D2 A can read and write the capability list of D1 A can read data from D3 B can read and write data from/to D3 Answer the following questions: Can data from D3 ever get into D1? Can data from D3 ever get into D2? Can data from D1 ever get into A? Can data from D2 ever get into A? Operating Systems 23

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

25 .Operating Systems 25 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 )

26 .Operating Systems 26 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

27 .Operating Systems 27 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

28 .Operating Systems 28 Information flow control additional requirement: service must not leak sensitive information the Confinement Problem the Selective Confinement Problem

29 .Operating Systems 29 Information flow control information flow control ≠ access control