Internal protection mechanisms
1 / 34

Internal Protection Mechanisms - PowerPoint PPT Presentation

  • Uploaded on

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

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about ' Internal Protection Mechanisms' - becca

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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
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

  • Combining Access Lists and Capability Lists

    13.4 Information Flow Control

  • The Confinement Problem

  • Hierarchical Information Flow

  • The Selective Confinement Problem

Access control environment
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
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 control1
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 control2
Instruction-level access control

  • protecting main memory

    • two issues:

      1. differentiate between types of access:


      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
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 access1
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 access2
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 access3
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 access4
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
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
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 lists1
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 lists2
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 lists3
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

Access lists vs capability lists4
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 lists5
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 lists6
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 lists7
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 lists8
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 lists9
Access lists vs capability lists

  • revocation of capabilities

    • use indirection via alias; destroy alias to revoke

Access lists vs capability lists10
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 lists11
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 lists12
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 lists13
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
Information flow control

  • additional requirement:

    • service must not leak sensitive information

  • the Confinement Problem

  • the Selective Confinement Problem

Information flow control1
Information flow control

  • informationflow control ≠access control

Information flow control2
Information flow control

  • Confinement using capabilities:

    • m-right necessary to modify (enables w-right)

  • before call

Information flow control3
Information flow control

  • aftercall

    • m-right removed from service except parameters

    • Total Confinement only

Information flow control4
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 control5
Information flow control

  • Example: confinement problem

    • during call, service executes at user level

    • can access user data but not owner data

Information flow control6
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 control7
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 control8
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