Lecture 18: Security and Protection
Topics for Today
- terminology
- access matrix model
- implementation of the access matrix model
Potential Information Security Violations
Unauthorized
- release
- modification
- denial of service
Aspects of Security
- external = access to computer system
- internal = allowed actions within the computer system
- policies - how we decide what to do
- mechanisms - means by which it can be done
including protection mechanisms
- authentication = verification of user's identity
Implementing protection mechanisms in real operating systems
- Writing a new OS from scratch costs too much
- Getting people to use a new OS is difficult
- New OS technology is adopted if it can be added onto
an existing OS
- Otherwise, it is not adopted
- How to implement security?
Protection versus Security
- protection -- mechanisms
e.g., putting locks on doors
- security -- policies,
which specify how protection mechanisms are to be used
e.g., who gets keys? when are doors locked?
- protection domain of a process
- resources process can access
- operations it can perform on those resources
- good policy is to restrict domain to what is needed
Design Principles
- economy - overhead is tolerable
- complete mediation - all requests are checked
- open design - does not depend on attacker's ignorance
- separation of privileges
- least privilege
- least common mechanism
- acceptability
- fail-safe defaults
Example: Unix (Solaris) Protection Mechanisms
- file access modes
- read, write, execute
- owner, group, others
- set user ID on execution
- set group ID on execution
- enable mandatory locking
- turn on sticky bit
- access control lists (setfacl, getfacl)
- memory protection
- shared memory permissions
Protection System Models
- abstract
- do not necessarily directly match any implementation
Access Matrix Model
- O = current objects, e.g., a file, a process
- S = current subjects, e.g., a process
- R = generic rights, e.g., read, write, execute, delete
- P = access matrix, indexed by (subject, object)
Enforcement of Model
When subject s wants to access a to object o,
system views this as request (s,a,o)
to monitor of o.
Monitor permits access iff a Î P(s,o).
Example of Access Matrix
| | o1 | o2 | s1 | s2 | s3 |
|---|
| s1 | read, write | own, delete | own | sendmail | recmail |
| s2 | execute | copy | recmail | own | block, wakeup |
| s3 | own | read, write | sendmail | block, wakeup | own |
Does one actually ever store this matrix?
Implementation Methods
- capability list = collapsed row of access matrix
- access control list = collapsed column of access matrix
- lock-key = combination
Capabilities
- capability = tuple (o, P(s,o))
- each subject has a set of capabilities
- posession of capability confers access rights
Capability Based Addressing
How does this relate to segmented/paged virtual memory?
Implementing Capabilities
- tagged memory
- partitioned memory
Capability Pros & Cons
- efficiency - no need to explicit check permissions for each access
- simplicity - a single mechanism, based on adressability
- flexibility - can control access by granting capabilities
- propagation control - can pass on rights
- review - who currently has rights?
- revocation - cannot revoke rights
- garbage collection - when can object be reclaimed?
Access Control List
- list contains pairs (s, P(s,o))
- when subject s wants to access a to object o
- search ACL of o for entry corresponding to s
- check whether this entry contains a
ACL Example
| Subjects | Access Rights |
|---|
| Chang | read, write, execute |
| Xu | read |
| Wang | write |
| Yang | execute |
| Yu | read, write |
ACL Pros & Cons
- slow access time
- difficult review of accessibility, by subject
- easy revocation
- easy review of acessibility, by object
- amenable to protection groups, which saves storage
- right to change protections easily controlled
Changing Protections
- self control, by owner
Can you relate this to UNIX file protection?
- hierarchical control, with a tree of processes
Can you relate this to UNIX process protection?
Lock-Key Method
- each subject has capability list of tuples (o,k),
where k is a key
- each object has ACL of tuples (k,A),
where A is a set of access modes
- when s wants access a for object o
- find a tuple (o,k) in s's capability list
- find a matching tuple (k,A) in o's ACL,
such that a Î A.
- revocation is easy