internal protection mechanisms
Download
Skip this Video
Download Presentation
Internal Protection Mechanisms

Loading in 2 Seconds...

play fullscreen
1 / 34

Internal Protection Mechanisms - PowerPoint PPT Presentation


  • 154 Views
  • 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

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
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:

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
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
ad