1 / 47

Protection in Operating Systems

Protection in Operating Systems. Well, a brief consideration of it. There is too much material to cover this in any great depth. Security Features. User authentication Memory Protection Each user’s program must run in a portion of memory protected from unauthorized access

Télécharger la présentation

Protection in Operating Systems

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Protection in Operating Systems Well, a brief consideration of it. There is too much material to cover this in any great depth. 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 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 CS 395: Computer Security

  4. 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 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 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 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 CS 395: Computer Security

  9. Memory and Address Protection • Virtual Memory is all about this (you read it) 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 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 CS 395: Computer Security

  12. Access Control Goals • Check every access • 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 CS 395: Computer Security

  13. General Access Control Mechanisms • Directory • Access control list • Access control matrix • Capability 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 CS 395: Computer Security

  15. Directory CS 395: Computer Security

  16. Directory • Advantages • 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 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) 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! CS 395: Computer Security

  19. 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: CS 395: Computer Security

  21. 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. 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. 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. 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) 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. 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. 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 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). CS 395: Computer Security

  29. User Authentication E.g., How can I tell you’re you? 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 CS 395: Computer Security

  31. Passwords • Most common means of user authentication to OS • Although secure in theory, human practice often degrades quality of this means of authentication • Must handle: • Loss: depending on implementation, it is possible that no one will be able to restore a lost password. • Use: Supplying password for each file access can be inconvenient and time consuming. • Disclosure: If password disclosed to unauthorized individual, file becomes immediately accessible. If password is then changed, all other legitimate users must be notified. • Revocation: To revoke one user’s access rights to a file, someone must change the password, causing same problems as disclosure. CS 395: Computer Security

  32. Aside: Multifactor Authentication • This is fancy name for use of additional authentication information • E.g., log in allowed only if password check is valid and • Log in request received from specific IP address and/or port AND • Log in request received during specific time period (say between 8 a.m. and 5 p.m. • Two forms if authentication (two-factor authentication) better than one if both are strong • But as number of forms increase, so does inconvenience • AND each authentication factor requires system to manage more security info (which, in addition to increased protection resources) may also increase complexity of implementation CS 395: Computer Security

  33. Attacks on Passwords • Passwords limited as protection devices because of the relatively small number of bits of info they contain • Ways to obtain user’s password (in decreasing order of difficulty) • Try them all • Try frequently used passwords • Try passwords likely for the particular user • Search for system list of passwords • Ask the user • Systems don’t help here, as they often provide attacker with partial information. CS 395: Computer Security

  34. Loose-Lipped Systems • Note password authentication is based on premise that user knows nothing of the system. But systems often help an attacker • Consider system messages look like above (uppercase is system message, lowercase is user) • System is identified, and attacker knows adams is not a valid user name. Intruder can use this with common surnames to build a list of authorized users. CS 395: Computer Security

  35. Loose-Lipped Systems • Better: User is not told whether it is the username or the password that is bad • But message still provides name of the system. CS 395: Computer Security

  36. Loose-Lipped Systems • Best: adversary receives no information until after successful authentication. • After all, legitimate user should know the name of the system, so why provide it beforehand? CS 395: Computer Security

  37. Exhaustive Attack • A.k.a. brute-force attack, is when attacker tries all passwords (usually in an automated fashion) until correct one is found • Difficulty depends on implementation (how long are passwords, etc) • Example: Assume passwords consist of 26 characters from A-Z, and can have length from 1 to 8 characters. • Num. Passwords = 261 + 262 + 263 +…+ 268 = 269 -1 ≈ 5 x 1012 • At one password/millisecond, takes 150 years • At on password/microsecond, takes two months! • Reasonable time if reward is large enough (e.g. password protecting file of credit card numbers) • And expected search times, if all passwords random, is half these times CS 395: Computer Security

  38. Probable Passwords • Reduce search space significantly! • When humans choose words at random, they tend to choose words that are short, common, and easy to spell and pronounce. • Attackers use this info: • Search passwords from shortest to longest • All passwords 5 chars or less can be searched in under 4 hours. • Time given assumes people choose all passwords with equal probability (e.g. hdlzm, ehlzx are chosen as often as pizza and beer) • Spell-checkers often have dictionaries of commonly used words • One of these contains 80,000 words. Trying all of them takes only 80 seconds. CS 395: Computer Security

  39. Passwords Likely for a User • Usually meaningful to the person • Name of spouse, child, brother, sister, pet, street name, or something memorable or familiar • List of these things is often only a few hundred entries long at most. Can be checked in under a second! CS 395: Computer Security

  40. Distribution of Actual Passwords • 1979 study by Morris and Thompson • Considered 3,289 passwords • Results: • 15 were single ASCII characters • 72 were two ASCII characters • 464 were three ASCII characters • 477 were four alphabetic letters • 706 were five alphabetic letters, all same case • 605 were six lowercase alphabetic letters • 492 were words in dictionaries or lists of names • Total: 2831 (86%) contained in this list! CS 395: Computer Security

  41. Figures are Not Dated • 1990: Klein collected appx 15,000 passwords • 2.7% guessed within 15 minutes, 21% within one week • 1992: Spafford collected appx 15,000 passwords • Average length 6.8 characters • 28.9% consisted of only lowercase alphabetic characters • 2002: British online bank Egg finds 50% of passwords for online banking service were family members’ names: • 23% children’s names • 19% spouse or partner • 9% their own name • 8% pet names • 9% each for celebrity and soccer star’s names CS 395: Computer Security

  42. Still Worse • 1998: Knight and Hartley report appx 35% of passwords derived from syllables and initials of account owner’s name. • Several articles claim that God, sex, love, and money are four most common passwords • Lists of common passwords posted online • http://www.geodsoft.com/howto/password/common.htm • http://www.phenoelit.de/dpl/dpl.html • Also sites that post dictionaries of phrases, science fiction characters, places, mythological names, Chinese words, Yiddish words, and several other specialized lists • Sysadmin utilities such as SATAN, COPS, and Crack allow administrators to check for weak passwords. They also allow attackers to do the same. • Changing letters to numbers (e.g., 0 for letter O, 1 for lowercase L, etc): been done, and the attackers know it. CS 395: Computer Security

  43. Knight and Hartley 12 Password Guessing Steps • No password • The same as the user ID • Is, or is derived from, the user name • Common word list (e.g., password, secret) plus common names and patterns (e.g., asdfg, aaaaaa) • Short college dictionary • Complete English word list • Common non-English language dictionaries • Short college dictionary with capitalizations (PaSsWorD) and substitutions (0 for O, etc) • Complete English with capitalizations and substitutions • Common non-English dictionaries with capitalizations and substitutions • Brute force, lowercase alphabetic characters • Brute force, full character set CS 395: Computer Security

  44. Plaintext System Password List • Not a good idea • Even if protected via access control (e.g., only OS level functions can access it) it’s not good • Many OS functions never need to read the file, and opening it to all OS functions means that if even one of these functions is compromised, password list is compromised as well • System backups often lack protection mechanisms (physical security and access control to the backup tapes themselves are only security for these). • Password file is stored on a disk, so anyone who can overcome file restrictions or have access to disk can obtain password file. CS 395: Computer Security

  45. Encrypted Password File • Password table entries are encrypted using a one way function (e.g. hash) and then stored. • One log in, hash of user password is checked with entry in the password file. • A problem: two users who pick same password will notice that they have the same password hash • Salt: A small number formed from other info, and appended to password • Password + salt is what is hashed • Salt stored in plaintext. On authentication attempt, OS appends salt to the password and hashes the extended password to check against password file. • E.g., Unix salt is a 12-bit number formed from system time and process ID. • Still a good idea to limit access to password file (even if encrypted) CS 395: Computer Security

  46. Indiscreet Users • Tape password to side of terminal or write it down on card just inside top desk drawer • Users sharing files share passwords “my password is x, just get the file yourself” • Verisign (2005) in unscientific poll found that 2/3 of people approached on street volunteered to disclose their password in exchange for coupon good for a cup of coffee. 79% admitted they use same password for multiple systems or sites. CS 395: Computer Security

  47. One-Time Passwords • A password that changes every time it is used (so if password is intercepted, it’s not useful) • Rather than a static phrase, system assigns a static mathematical function to user. System provides the argument to function, user computes and returns function value. • A.k.a. challenge-response system because system presents challenge to user • Very simple examples: • f(x) = some polynomial, the xth prime number, etc. • f(x) = r(x) for some fixed pseudorandom number generator. Server provides the seed. • f(E(x)) = E(D(E(x)) + 1) CS 395: Computer Security

More Related