Protection rings

• privilege separation: like user mode & kernel mode
• HW support: required to support notion of separate execution
• let: $D_i,D_j$ be any two domain rings
  • if $j<i⟹D_i\subseteq D_j$
  • 👨‍🏫 hierarchical!
• the innermost ring: ring 0: provides the full set of privileges
• 
• components: ordered by amount of privilege
  • & protected from each other
  • e.g. kernel & user: different ring
  • privilege separation: requires HW support
  • "gates": used to transfer between rings
    • e.g. syscall instruction, traps, and interrupts
• hypervisor (Intel): introduced
  • extended VM managers
  • creating & running VM
  • more capabilities than kernels of the guest OS
• ARM processors: added TrustZone (TZ) to protect: crypto functions w/ access

ARM CPU architecture

Domain of protection

• problem: rings being a subset of another
• domain: a generalization of rings without a hierarchy
  • 👨‍🏫 they can be disjoint of one another, too!
• computer system: can be treated as processes / objects
  • hardware objects (CPU, memory, disk)
  • software objects (files, programs,semaphores)
• process: should only have access to objects it currently requires to complete tasks
  • need-to-know principle (policy)
• implementation: via process operating in a protection domain
  • protection domain: specifying set of resources a process may access
  • each domain: specifying set of objects / types of operations may be invoked on each object
• access right: ability to execute an operation on an object
• domain: collection of access rights, each being an ordered pair
  • <object-name, rights-set>
• domains: may share access rights
• process-domain associations: can be static
  • if set of resources available to the process:
    • fixed throughout the process's lifetime
• also: it can be dynamic
  • 👨‍🏫 can support more precise principle of least privilege
  • then: some mechanism must allow domain switching
    • enables: process to switch from a domain to another
      • during different stage of execution
• domain: can be realized in a variety of ways
  • each user: may be a domain
    • set of objects accessible: depending on user
    • domain switch: when the user changes
  • each process: may be a domain
    • set of objects accessible: depending on process
    • domain switch: when a process sending a message to another
      • and waiting for a response
  • each procedure: may be a domain
    • set of objects accessible: depending on local variables defined in procedure
    • domain switch: when procedure call is made

Domain structure

• access right
• two domains: independent
  • can be disjoint, etc.
• 

Access matrix

• access matrix: view protection: as a matrix
• rows: domains
• columns: objects
• access[i,j]: set of access rights of domain i on object j

Use of access matrix

• access matrix scheme: providing mechanism for specifying a variety of policies
• mechanism: consists of implementing access matrix / ensuring that semantic properties hold
  • to ensure a process executing in domain:
    • $D_i$ can access only objects specified in row $i$
• policy decisions: specify which rights should be included in $(i,j)$-th entry
  • and determine: domain for each process to execute

• idea: can be expanded to dynamic protection
  • operations: to add / delete access rights
• special access rights
  • owner of $O_i$: can add / remove any right in any entry in column
  • copy op from $O_i\to O_j$ (denote: *)
    • only within the column (i.e. for the object)
  • control: $D_i$: modify $D_j$ access rights
    • modify domain objects (a row)
  • transfer: switch from domain $D_i\to D_j$
• copy & owner: applicable to an object
  • change: the entries in a column
• control: applicable to domain object
  • changing entries in a row
• new objects / domains: can be created dynamically
  • and included in the access-matrix model
• d

Access matrix w/ copy rights

• 
• while executing read on $F_2$ within domain $D_2$
  • it can copy $F_2$

Access matrix w/ owner rights

• 
• as a owner: anything within the column can be changes

Access matrix (modified)

• some domain: has control over another domain
• 

Access matrix implementation

• generally: access matrix is sparse
  • thus: most of entries will be empty
• option 1: global table
  • store: ordered triples <domain, object, rights-set> in table
  • requestie op
  • each column: Access-control list for one object
    • define: who can perform what operation

    domain 1: read, write
    domain 2: read
    domain 3: read
    ...
    

  • each row: capability list (like a key)
    • for each domain: what operations allowed on what objects

    object 1: read
    object 2: read, write, execute
    object 3: read, write, delete, copy
    ...
    

    • 👨‍🏫: can be a very long list, as there may be many objects
• option 2: access lists for objects
  • each column: implemented as an access list for one object
  • resulting per-object list: consists of ordered pairs
    • <domain, rights-set>
    • defining: all domains w/ non-empty set of access rights for the object
  • empty entries: can be discarded
  • also: a default set of access rights can be dreaded
    • allow access to any domain, if M ∈ default set
• option 3: capability lists for domains
  • instead of object-based: list being domain-based
  • capability list for domain: list of object
    • together w/ operations allowed on them
  • an object: represented by its name / address (capability)
  • to execute operation $M$ on object $O_j$,
• option 4: lock-key
  • compromise between: access lists & capability lists
  • each object: w/ list of unique bit patterns: locks
  • each domain: w/ list of unique bit patterns: keys
  • 👨‍🏫 same for each operations
  • match: some binary operation
    • without description in text
  • process in domain: can only access obj if:
    • domain w/ key that matching: one of locks of the object
  • 👨‍🏫 without much description even in the textbook!
  • not implemented commonly

Comparison of implementations

• choosing a right technique: involving trade-offs
• global table: simple, yet large
  • lack of grouping of objects / domains
• access lists: correspond directly to the needs of users
  • access list on an object: specified when a user creates the object
  • determining set of access rights for each domain: difficult
    • every access to the object: must be checked
      • requiring: search of the access list
• capability list: useful for localizing information for a given process
  • yet: revocation capabilities can be inefficient
• lock-key: can be effective & flexible, depending on the length of the keys
  • keys: can be passed freely from domain to domain
    • easy revocation!
• most systems: use combination of access lists / capabilities
• 👨‍🏫capability list: can be done with hash map
  • however: can cause trouble trouble to access-control list

Final exam

• only post-midterm content is covered
• which is... still quite a lot!
  • Ch. 6, 7, 8, 9, 10, 11, 12, 13, 14, 17
• Q&A session: may be arranged