1. Protection in Operating Systems
Well, a brief consideration of it. There is too much material to cover this in any great depth.
Fall 2006
CS 395: Computer Security

2. Security Features User authentication Memory Protection
Each user’s program must run in a portion of memory protected from unauthorized access
File and I/O device access control
OS must protect user and system files from unauthorized modification
Allocation and Access Control to General Objects
E.g., constructs to permit concurrency and synchronization
Fall 2006
CS 395: Computer Security

3. Security Features (cont.)
Enforced Sharing (e.g., peripherals)
Requires need for integrity and consistency
Guaranteed fair service
No process should be starved from receiving service (e.g. CPU)
Interprocess Communication and Synchronization
Protected OS protection data
The data the the OS uses to enforce security must itself, of course, be secured
Fall 2006
CS 395: Computer Security

4. Fall 2006
CS 395: Computer Security

5. Security Methods
Separation: Keep users objects separate from other users. Can occur in several ways:
Physical Separation
Processes use different physical objects (e.g. two printers)
Temporal Separation
Processes executed at different times based on security requirements
Logical Separation
User and program have illusion that no other process exists
Cryptographic Separation
Data and processes unintelligible to outside processes
Increasing complexity
Fineness of protection
Fall 2006
CS 395: Computer Security

6. A Problem
Sharing: processes at different security levels may need to share resources
E.g. Library routines, search algorithms, peripherals, etc.
So the problem: how to separate users and their various objects, while at the same time providing sharing for some of those objects
Fall 2006
CS 395: Computer Security

7. Separation and Sharing
Do not protect
OS with no protection appropriate if processes are run at separate times
Isolate
Concurrently running processes unaware of each other. Each process has its own objects
E.g., address space, files
Share all or share nothing
Owner of object declares it public or private
Increasing complexity
Fineness of protection
Fall 2006
CS 395: Computer Security

8. Separation and Sharing
Share via access limitations
OS checks allowability of each user’s potential access to an object
E.g., access control implemented for specific users and specific objects, usually via a list of acceptable actions.
Share by capabilities
Extension of limited access sharing allows dynamic creation of sharing rights for objects
Can depend on context, owner, subject, etc.
Limit use of object
E.g., may read sensitive document, but not print it
E.g., may access statistical summaries of data, but not individual entries
Fall 2006
CS 395: Computer Security

9. Memory and Address Protection
Virtual Memory is all about this (you read it)
Fall 2006
CS 395: Computer Security

10. General Access Control
Memory relatively easy: every access guaranteed to go through certain points in hardware
With general objects:
Number of access points may be large
May be no central authority through which all accesses pass
Access may not be limited to read, write, or execute
Fall 2006
CS 395: Computer Security

11. General Access Control
Memory relatively easy: all accesses to memory through a program, so we can refer to program (or programmer) as accessing agent
With general objects:
User (or subject) could be:
Person who uses computing system
Program
Programmer
Another object
Something else that seeks to use an object
Fall 2006
CS 395: Computer Security

12. Access Control Goals Check every access Enforce Least Privilege
May want to revoke users privilege to access an object (I.e. no indefinite access to object)
May want to prevent further access immediately after revocation
Enforce Least Privilege
Subject should have access to least number of objects necessary to perform task, even if extra information appears to be useless or harmless.
Verify Acceptable Usage
Access to object may be yes-no decision, but equally important to check activity to be performed on object is appropriate
E.g. Stack: only push, pop, clear, etc. are acceptable
Fall 2006
CS 395: Computer Security

13. General Access Control Mechanisms
Directory
Access control list
Access control matrix
Capability
Fall 2006
CS 395: Computer Security

14. Directory Works like a file directory
Every file (object) has a unique owner who controls access rights (including the right to declare who has what access) and controls revocation of those rights
Fall 2006
CS 395: Computer Security

15. Directory
Fall 2006
CS 395: Computer Security

16. Directory Advantages Difficulties Easy to implement
One list per user, listing all accesses
Difficulties
List becomes too large if many shared objects are accessible to all users
Directory of each user must have entry for each such shared object (even if user never uses object)
Deletion of object must be reflected in all directories
Access revocation
If A passes access right for object F to B, then entry for F is created in B’s directory
Revocation of access rights for everyone requires search of each individual directory entry for right to F (could be 10,000 directories)
And B may have passed access rights for F to another user, so user can’t be counted on to know that this new user’s rights should be revoked
Fall 2006
CS 395: Computer Security

17. Directory Pseudonyms: another difficulty
A and B could have two different files named F, and they both may want to allow access by S. Directory for S clearly cannot have two entries under same name for different files.
S must be able to uniquely identify F for A (or B).
One approach: include original owner’s designation as part of file name (e.g. A:F)
Fall 2006
CS 395: Computer Security

18. Thorny Directory Problem
User S has trouble remembering contents of F from the name, so wants to rename it.
So subject S is allowed to rename file to any name unique to the directory of S. So F from A could be called Q to S.
S later forgets that Q is F from A, and so requests access again from A for F.
But now A may have more trust in S, so it grants greater access rights
Leaves open the possibility that S may have two different sets of access rights to F, one under the name F, one under the name Q. Thus pseudonyms can lead to multiple (and inconsistent) permissions for a given object
Bottom line: too simple for most object protection situations!
Fall 2006
CS 395: Computer Security

19. Fall 2006
CS 395: Computer Security

20. Access Control List One such list for each object
Shows all subjects who should have access to the object and what their access is
Different from directory because one access control list per object; whereas a directory is created for each subject
This may seem trivial, but it provides some significant advantages:
Fall 2006
CS 395: Computer Security

21. Consider subjects A and S, both with access rights to F
Consider subjects A and S, both with access rights to F. The OS maintains a single access list for F, showing access rights for A and S. List can contain default rights for some users, custom rights for others. So, public object can be shared by all possible users of system without need for object entry in individual directory of each user.
Fall 2006
CS 395: Computer Security

22. Access Control Matrix
Directory: list of objects accessible by single subject
Access Control List: table identifying subjects that can access a single object
Two hold equivalent information. Distinction lies in ease of use in given situations.
Access Control Matrix: each row represents a subject, each column an object.
Entries are access rights for specific subject to specific object
In general a sparse matrix (most subjects don’t have access rights to many objects)
Can be implemented as a list of <subject, object, rights> triples, though rarely done because of inefficiency of searching a large number of such triples.
Fall 2006
CS 395: Computer Security

23. Capability
Places some of the burden of protection and rights on the user
Capability is an unforgeable token that gives the possessor specific rights to an object.
Subject can create object and specify operations allowed on that object (e.g., read, write, execute permissions on files, subprocesses, data segments)
User can also define completely new objects (e.g., new data structure) and can define types of accesses previously unknown to OS.
Fall 2006
CS 395: Computer Security

24. Capabilities (cont.)
Capability is a ticket, and thus should be unforgeable
Alternative 1: OS control
Ticket is not given directly to user, but instead held by OS on behalf of users.
OS returns to user a pointer to OS data structure that also links to user.
Capability created only by specific request from user to OS
Alternative 2: Capability encrypted under key available only to access control mechanism
If encrypted capability contains identity of rightful owner, capability cannot be forged (I.e. copied and given to another user)
Fall 2006
CS 395: Computer Security

25. Capabilities: Odds and Ends
One possible access right to object is transfer or propogate
Subject with this right can pass copies of capabilities to other subjects
These passed capabilities has a list of permitted access types, one of which might also be transfer
Subprocedures: Process calling a subprocedure needs to pass access rights (e.g., to read) for some objects (the subprocedure parameters).
When objects passed to subprocedure, OS forms a stack of all capabilities of the current procedure, and creates new capabilities for the subprocedure.
Fall 2006
CS 395: Computer Security

26. Capabilities: Odds and Ends
Capabilities a straightforward method for tracking access rights during execution
Though usually backed up by more comprehensive table such as access control matrix.
During execution, only capabilities of objects accessed by current process are kept available (for improved access speeds)
Revocation:
If issuing subject revokes capability, no further access under capability is permitted
Capability table contains pointers to active capabilities spawned under a capability, so OS can trace access rights that need to be revoked when a capability is revoked.
Fall 2006
CS 395: Computer Security

27. Kerberos
Implements both authentication and access authorization using capabilities (called tickets), secured with symmetric key crypto.
Microsoft NT+ access control based largely on Kerberos
Requires two systems: authentication server (AS) and ticket-granting server (TGS), both part of key distribution center (KDC)
User presents authenticating credential (e.g., password) to AS and receives an encrypted ticket indicating that user has passed authentication
Encryption prevents forging of tickets and use of ticket by an impersonator
Fall 2006
CS 395: Computer Security

28. Kerberos
Single sign-on: User signs on once, and from that point on all user’s allowable actions authorized without need for signing on again.
Works even between domains, companies, etc, as long as authorization rights established between two domains.
System works via shared secret encryption keys
Each user’s password is an encryption key and is stored only at the ticket granting server.
This method means that passwords are never exposed (via the network).
Fall 2006
CS 395: Computer Security

29. E.g., How can I tell you’re you?
User Authentication
E.g., How can I tell you’re you?
Fall 2006
CS 395: Computer Security

30. The Basics
Unlike “real world” authentication (e.g., you recognize someone’s voice over the phone) computer can’t “recognize” someone (well, not in the same way).
Three quantities used to confirm user’s identity
Something the user knows
Passwords, PIN numbers, secret handshake, mother’s maiden name
Something the user has
Identity badge, physical key, driver’s license, uniform
Something the user is
Biometrics: based on physical characteristics of user (e.g., fingerprint, pattern of person’s voice, picture of face).
These three can be combined
Fall 2006
CS 395: Computer Security