[UCSD CSE120]保护-protection

本文是我在上UCSD的 CSE 120: Principles of Operating Systems (Winter 2020) 整理的笔记，这一课主要介绍了操作系统里面对文件和进程资源的保护方法，包括用户权限和用户组管理。

Basics

1. Introduction

   • Process access resources

   • Resources are shared, need to be protected

     • from process without permission
     • from improper access by a process

   • What is the right protection model?

   • What are the mechanism?

2. The kernel enforces protection

   • To pretect resources, have kernel “own” them, then kernel can allow access temporairily
   • To access a resource, a process must ask for it, then kernel can test whether access should be given

   • One a process is given access

     • kernel can prevent others for gaining access
     • kernel may/may not be able to take away access

   • This assumes kernel operates correctly

3. Protecting the kernel

   • The kernel itself must be protected

   • Mechanism

     • Memory protecion
     • Protected mode of operation: kernel vs. user
     • Clock interrupt, so kernel eventually gets control

   • Notice, mechanisms are hardware supported

   • Protected kernel can protect other resources

4. Goals supported by kernel

   • Allow range of permissions
   • Allow user to set/get them
   • Be fast/simple for common use
   • Support user expressing complex permissions

Implementation

Simple model

1. A formal model of protection

   • Protection: how to limit access to a resource
   • Resource: object that requires protection
   • Domain: set of (resource, permission) pairs
   • Process: accesses resources within domain

2. Protection Matrix

   • Example: (X, Y: Resources A,B: Domains)

     | | X | Y | A | B |
     |—-|—- | —- |—-|—-|
     | A | r,w | r,w | | |
     | B | w | r | | |

   • Can describe all domains as a matrix

     • Rows are domains
     • Columns are resources
     • Matrix entry [d, r] contains permissions/rights

   • Access Control Lists (For resource)

     • For each resource, list (domain, permissions) pairs
     • ACL is associated with resource
     • Like a registry: if name is on list, ok to access
     • Can be inefficient: must lookup on each access
     • Revocation is easy; just remove from list

   • Capability Lists (For domain)

     • For each domain, list (resource, permissions pairs)
     • Capability list associated with each domain
     • Like key/ticker: if you have it, you get access
     • Efficient: on access, just produce capability
     • Hard to revoke

UNIX Protecion

1. Basic

   • Associated with each file is set of permissions

     • Permission bits r/w/x for owner, group, world
     • Limited form of access control list

   • Protection domain: UID (user account ID) + …

     • A process is always in some domain

   • When process opens file, check permission

   • If ok, provide process with a capability

     • Future operations then carried out efficiently

2. More

   • For common case, r/w/x for o/g/w adequate
   • For special cases, can extend via user program
   • SETUID mechanism: causes domain switch

   • If executable file has SETUID bit set

     • Process runs in domain of owner (of executable)
     • Therefor, it runs with all the rights of the owner

3. Example

   • Pat has a file “Bil” of bibliography references
   • Chris wants to read and add entries
   • But, Chris lacks permissions (only Pat can r/w)
   • Pat wisher to allow append access (only add entris to the back), but how?

   • Solution:

     • Pat can provide program (e.g., EditBib): only reads/appends

     • Set permissions

       • of program: execute (for Chris), and SETUID on
       • of Bib file: read/write only for Pat, not Chris

     • When Chris executes EditBib, runs as Pat (since SETUID on, domain switch to Pat’s domain)

     • Program only does read/append.