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

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

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

Fall 2006 CS 395: Computer Security

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

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

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

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

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

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

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

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

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

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

Directory Fall 2006 CS 395: Computer Security

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

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

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

Fall 2006 CS 395: Computer Security

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

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

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

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

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

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

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

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

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

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

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