Internal Protection Mechanisms 13 1 The Access Control

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 Operating Systems 1

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 Operating Systems 2

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 Operating Systems 3

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) – memory mapped devices: • use memory protection mechanisms to restrict access Operating Systems 4

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 111 unrestricted access 2. confine program to assigned areas Operating Systems 5

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) Operating Systems 6

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); } Operating Systems 7

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 Operating Systems 8

Main memory access • Example: Windows – Page Table: • kernel/user mode access • access type (none, r, rw, x, rwx) • free/reserved/committed • copy on write Operating Systems 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 selfmodification) – only read/write data sandbox Operating Systems 11

High-level access control • enforced by software, e. g. file system • access matrix model – resources, subjects, rights R 1 R 2 R 3 R 4 S 1 rw rwx S 2 x rwx S 3 rwx r r • implemented as – access list: – capability list: R 1: (S 1, rw)(S 3, rwx); S 1: (R 1, rw)(R 2, rwx); R 2: (S 1, rwx)(S 2, r)(S 3, r); S 2: (R 2, x)(R 3, rwx)(R 4, rwx); R 3: … S 3: … • Analogy: access to conference/restaurant vs theater Operating Systems 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) Operating Systems 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 Operating Systems 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 R 1 R 2 R 3 R 4 R 5 S 1 rw rwx S 2 x rwx rwx S 3 rwx r r * r – access list for R 5: (S 2, rwx)(*, r) • CL – must find all subjects – future subjects not automatically included Operating Systems 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 Operating Systems 16

Access lists vs capability lists • adding/removing resources • AL: easy, implement owner right – creator of new resource becomes owner (o-right) R 1 rw R 2 rwxo x r R 3 R 4 R 5 S 1 S 2 rwxo S 3 rwxo 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 Operating Systems 17

Access lists vs capability lists • adding/removing subjects R 1 R 2 R 3 R 4 R 5 S 1 rw rwx S 2 x rwx rwx S 3 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 Operating Systems 18

Access lists vs capability lists • adding/removing rights R 1 R 2 R 3 R 4 R 5 S 1 rw rwxo S 2 x rwxo S 3 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 Operating Systems 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 Operating Systems 20

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

Access lists vs capability lists • revocation of capabilities – use indirection via alias; destroy alias to revoke Operating Systems 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 Operating Systems 24

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

Access lists vs capability lists • R 3: allow owner to revoke access – AL: remove user from list – CL: use alias, or destroy and recreate service with new capability • R 4: 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 Operating Systems 26

Access lists vs capability lists • R 5: service must access its own resources without giving access to user – AL: implement rights amplification during call (e. g. , setuser-id in Unix) – CL: service has its own capability list • R 6: 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 Operating Systems 27

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

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

Information flow control • Confinement using capabilities: – m-right necessary to modify (enables w-right) • before call Operating Systems 30

Information flow control • after call – m-right removed from service except parameters – Total Confinement only Operating Systems 31

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 Operating Systems 32

Information flow control • Example: confinement problem – during call, service executes at user level – can access user data but not owner data Operating Systems 33

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 Operating Systems 35

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) Operating Systems 36

Information flow control • Sneaky signaling: – use covert channels (not reflected in matrix) – Example: • Service: if salary>$100 k, 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 Operating Systems 37