Protection in Operating Systems

Fall 2006 CS 395: Computer Security 1

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

• 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


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



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

Incr

easi

ng c

ompl

exit

y Fineness of protection


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


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

Incr

easi

ng c

ompl

exit

y Fineness of protection


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


Memory and Address Protection

• Virtual Memory is all about this (you read it)


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


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


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


General Access Control Mechanisms

• Directory• Access control list• Access control matrix• Capability


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


Directory


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


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)


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!



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:


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.


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.


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.


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)


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.


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.


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


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).


User Authentication

E.g., How can I tell you’re you?


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


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.


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


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.


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.



• Better: User is not told whether it is the username or the password that is bad

• But message still provides name of the system.



• 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?


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


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.


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!


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!


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


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.

http://www.geodsoft.com/howto/password/common.htm

http://www.geodsoft.com/howto/password/common.htm

http://www.phenoelit.de/dpl/dpl.html


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


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.


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)


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.


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)

Documents

Protection in Operating Systems