Chapter 3 Os System Security

7/28/2019 Chapter 3 Os System Security

1/25

Chapter 3: OPERATING SYSTEM SECURITY

Protected Objects and Methods of Protection

Protected Objects

In fact, the rise of multiprogramming meant that several aspects of a computing systemrequired protection:

memory

sharable I/O devices, such as disks

serially reusable I/O devices, such as printers and tape drives

sharable programs and subprocedures

networks

sharable data

Security Methods of Operating Systems

The basis of protection is separation: keeping one user's objects separate from otherusers.

1) Physical separationo Different processes use different physical objects

E.g., different printers for different confidentiality levels ofoutput

2) Temporal separationo Processes having different security reqs executed at different times

3) Logical separationo Illusion that OS executes processes only for single user

4) Cryptographic separationo Processes conceal their data and computations from other processes

5) Combinations of the above

***IMP***

Strength of security via separation (least to most secure):Logical separationTemporal separationPhysical separation

Complexity of implementation of separation (least to most complex):

Physical separation


2/25

Temporal separationLogical separationCryptographic separation

Resource utilization in different kinds of separation: Poor: physical separation / temporal separation

Good: logical separation / cryptographic separation

1) Memory and Address Protection

Most obvious protection:Protect pgm memory from being affected by other pgms

a. Fenceb. Relocation

c. Base/Bounds Registersd. Tagged Architecturee. Segmentationf. Paging

Memory and Address Protection

The most obvious problem of multiprogramming is preventing one program fromaffecting the data and programs in the memory space of other users. Fortunately,protection can be built into the hardware mechanisms that control efficient use ofmemory, so solid protection can be provided at essentially no additional cost.

1) Fence

The simplest form of memory protection was introduced in single-user operating systemsto prevent a faulty user program from destroying part of the resident portion of theoperating system. As its name implies, a fence is a method to confine users to one side ofa boundary.

In one implementation, the fence was a predefined memory address, enabling the

operating system to reside on one side and the user to stay on the other.

Another implementation used a hardware register, often called a fence register,

containing the address of the end of the operating system..

1)Fence Confining users to one side of a boundary

E.g., predefined memory address n between OS and user

User pgm instruction at address n (OSs side of the fence) not allowed to

execute


3/25

1. Fixed fence(wastes space if unusued by OS or blocks IOS from growing)

or2. Variable fence (cf. Fig. 4-2, p. 185)

Using fence register h/w register

Fixed fence Variable fence

***IMP***Relocation

Pgms written as if starting at location 0 in memory

Actually, starting at location n determined by OSBefore user instruction executed, each address relocated by addingrelocation factor n to it

Relocation factor = starting address of pgm in memory

Fence register (h/w register) plays role of relocation register as well

Bec. adding n to pgm addresses prevents it from accessing addresses below n

2) Base/Bounds Registers

A major advantage of an operating system with fence registers is the ability torelocate; this characteristic is especially important in a multiuser environment. With twoor more users, none can know in advance where a program will be loaded for execution.The relocation register solves the problem by providing a base or starting address. Alladdresses inside a program are offsets from that base address. A variable fence register isgenerally known as a base register.

Fence registers provide a lower bound (a starting address) but not an upper one.An upper bound can be useful in knowing how much space is allotted and in checking foroverflows into "forbidden" areas. To overcome this difficulty, a second register is oftenadded, as shown in Figure The second register, called a bounds register, is an upperaddress limit, in the same way that a base or fence register is a lower address limit.


4/25

BASE BOUND

This technique protects a program's addresses from modification by another user.When execution changes from one user's program to another's, the operating system mustchange the contents of the base and bounds registers to reflect the true address space for

that user. This change is part of the general preparation, called a context switch, thatthe operating system must perform when transferring control from one user to another.

With a pair of base/bounds registers, a user is perfectly protected from outsideusers, or, more correctly, outside users are protected from errors in any other user'sprogram. Erroneous addresses inside a user's address space can still affect that programbecause the base/bounds checking guarantees only that each address is inside the user'saddress space. For example, a user error might occur when a subscript is out of range oran undefined variable generates an address reference within the user's space but,unfortunately, inside the executable instructions of the user's program. In this manner, auser can accidentally store data on top of instructions. Such an error can let a userinadvertently destroy a program, but (fortunately) only the user's own program.

We can solve this overwriting problem by using another pair of base/boundsregisters, one for the instructions (code) of the program and a second for the data space.Then, only instruction fetches (instructions to be executed) are relocated and checkedwith the first register pair, and only data accesses (operands of instructions) are relocatedand checked with the second register pair. The use of two pairs of base/bounds registersis shown in Figure. Although two pairs of registers do not prevent all program errors,they limit the effect of data-manipulating instructions to the data space. The pairs ofregisters offer another more important advantage: the ability to split a program into twopieces that can be relocated separately.


5/25

3)Tagged Architecture***IMP***

Problem with base/bounds registers:high granularity of access rights (ARs)

Can allow another module to access all or none of its dataAll or none data within limits of data base-bounds registers

Solution: tagged architecture (gives low granularity of access rights)Every word of machine memory has 1 tag bits defining access rights tothis word (a h/w solution!)


6/25

Benefit of tagged architecture:Low (good!) granularity of memory access control

at memory word level

Problems with tagged architecture:

Requires special h/w

Incompatible with code of most OSs

OS compatible with it must:

Accommodate tags in each memory word

Test each memory word accessed

Rewriting OS would be costly Higher memory costs (extra bits per word)

4) Segmentation Benefits addressing + enhances memory protection for free

Effect of an unbounded number of base/bounds registers

Access bits set by OS

Tested every time instruction

accesses its location


7/25

Pgm segmentation:

Program divided into logical pieces (called segments)E.g. Pieces are: code for single procedure

/ data of an array / collection of local data values

Consecutive pgm segments can be easily stored in nonconsecutive

memory locations

Segmentation offers these security benefits:

Each address reference is checked for protection.

Many different classes of data items can be assigned different levels of protection.

Two or more users can share access to a segment, with potentially different accessrights.

A user cannot generate an address or access to an unpermitted segment.

Paging

One alternative to segmentation is paging. The program is divided into equal-sized pieces called pages, and memory is divided into equal-sized units called pageframes. (For implementation reasons, the page size is usually chosen to be a power oftwo between 512 and 4096 bytes.) As with segmentation, each address in a paging

scheme is a two-part object, this time consisting of .


8/25

Control of Access to General Objects

Protecting memory is a specific case of the more general problem of protectingobjects. As multiprogramming has developed, the numbers and kinds of objects sharedhave also increased. Here are some examples of the kinds of objects for which protectionis desirable:

memory

a file or data set on an auxiliary storage device

an executing program in memory

a directory of files

a hardware device

a data structure, such as a stack

a table of the operating system

instructions, especially privileged instructions

passwords and the user authentication mechanism

the protection mechanism itself


9/25

***IMP***

Objects and subjects accessing them

Generalobjects in OS that need protection (examples)

Memory / File or data set on auxiliary storage device

Pgm executing in memory / Directory of files / Hardware device Data structure / OS tables / Instructions, esp. privileged

instructions

Passwords and authentication mechanism / Protection mechanism

Subjects

User / Administrator / Programmer / Pgm

Another object / Anything that seeks to use object

Complementarygoals in access control:

1) Checkevery access

Access is not granted forevercan be suspended or revoked

2) Enforce least privilege

Give subject access to the smallest number of objects necessary toperform subjects task

3) Verify acceptable use

E.g., verify if requested kindof access is acceptable

E.g., R is OK, W/X is not

Control Access to the Object

1. Directory2. Access Control List3. Access Control Matrix

1) Directory(per object)

File directory mechanism to control file access

Unique object owner

Owner controls access rights: assigns/revokes them

Access rights (ARs): Read, write, execute (possible others)

Each user has access rights directory

Example: (User A owns O1 and O3. User B owns O2, O4, O5)


10/25

Advantage: Easy to implementJust one list (directory) per user

DifficultiesAll user directories get too big for large # of shared objects bec. eachshared object in dir. of each user sharing it

Maintenance difficulties:Deletion of shared objectsRequires deleting entry from each directory referencing it

Revocation of accessIf owner A revokes access rights for X from every subject, OS must search

dirs of all subjects to remove entries for X

2)Access Control List(Per subject)

There is one such list for each object, and the list shows all subjects who shouldhave access to the object and what their access is. This approach differs from thedirectory list because there is one access control list per object; a directory is created foreach subject. Although this difference seems small, there are some significantadvantages.


11/25

3) Access Control Matrix(per subject, per object)

We can think of the directory as a listing of objects accessible by a single subject,and the access list as a table identifying subjects that can access a single object. The datain these two representations are equivalent, the distinction being the ease of use in givensituations.

As an alternative, we can use an access control matrix, a table in which each rowrepresents a subject, each column represents an object, and each entry is the set of accessrights for that subject to that object. An example representation of an access controlmatrix is shown in Table. In general, the access control matrix is sparse (meaning thatmost cells are empty): Most subjects do not have access rights to most objects. The


12/25

access matrix can be represented as a list of triples, having the form . Searching a large number of these triples is inefficient enough that thisimplementation is seldom used.

File Protection Mechanisms

Basic forms of protection

Basic forms of protection

All-none protection

Group protection

1) All-none protection (in early IBM OS)

Public files (all) or files protecd by passwords (none)

Access to public files required knowing their names

Ignorance (not knowing file name) was an extra barrier

Problems w/ this approach

Lack of trust for public files in large systems

Difficult to limit access to trusted users only

Complexity for password-protected files, human response (password) required

for each file access

File names easy to find

File listings eliminate ignorance barrier

Group Protection

Because the all-or-nothing approach has so many drawbacks, researchers soughtan improved way to protect files. They focused on identifying groups of users who hadsome common relationship. In a typical Unix+ implementation, the world is divided intothree classes: the user, a trusted working group associated with the user, and the rest ofthe users. For simplicity we can call these classes user, group, and world. Windows NT+uses groups such as Administrators, Power Users, Users, and Guests. (NT+administrators can also create other groups.)

All authorized users are separated into groups. A group may consist of several

members working on a common project, a department, a class, or a single user. The basisfor group membership is need to share. The group members have some common interestand therefore are assumed to have files to share with the other group members. In thisapproach, no user belongs to more than one group. (Otherwise, a member belonging togroups A and B could pass along an A file to another B group member.)

When creating a file, a user defines access rights to the file for the user, for othermembers of the same group, and for all other users in general. Typically, the choices for


13/25

access rights are a limited set, such as {update, readexecute, read, writecreatedelete}. Fora particular file, a user might declare read-only access to the general world, read andupdate access to the group, and all rights to the user. This approach would be suitable fora paper being developed by a group, whereby the different members of the group mightmodify sections being written within the group. The paper itself should be available for

people outside the group to review but not change.

A key advantage of the group protection approach is its ease of implementation. Auser is recognized by two identifiers (usually numbers): a user ID and a group ID. Theseidentifiers are stored in the file directory entry for each file and are obtained by theoperating system when a user logs in. Therefore, the operating system can easily checkwhether a proposed access to a file is requested from someone whose group ID matchesthe group ID for the file to be accessed.

Advantage: Ease of implementation

OS recognizes user by user ID and group ID (upon login)

File directory stores for each file:File owners user ID and file ownersgroup ID

Problems with group protection

a) User cant belong to > 1 groupSolution: Single user gets multiple accounts

E.g., Tom gets accounts Tom1 and Tom2Tom1 in Group1, Tom2 in Group2

Problem: Files owned by Tom1 cant be accessed by Tom2 (unless they are public available to others)

Problems: Inconvenience,redundancy (e.g., if admin copies Tom1 files to Tom2 acct)

b) User might become responsible for file sharingE.g., admin makes files from all groups visible to a user (e.g., by copying them

into one of users accts and making them private users files)

=> User becomes responsible for manually preventing unauthorized sharing ofhis files between his different groups

c) Limited files sharing choicesOnly 3 choices for any file: private, group, public

Individual Permissions


14/25

In spite of their drawbacks, the file protection schemes we have described are relativelysimple and straightforward. The simplicity of implementing them suggests other easy-to-manage methods that provide finer degrees of security while associating permission witha single file.

Persistent Permission

From other contexts you are familiar with persistent permissions. The usualimplementation of such a scheme uses a name (you claim a dinner reservation under thename of Sanders), a token (you show your driver's license or library card), or a secret(you say a secret word or give the club handshake). Similarly, in computing you areallowed access by being on the access list, presenting a token or ticket, or giving apassword. User access permissions can be required for any access or only formodifications (write access).

All these approaches present obvious difficulties in revocation: Taking someone off one

list is easy, but it is more complicated to find all lists authorizing someone and removehim or her. Reclaiming a token or password is even more challenging.

Temporary Acquired Permission

Unix+ operating systems provide an interesting permission scheme based on athree-level usergroupworld hierarchy. The Unix designers added a permission called setuserid (suid). If this protection is set for a file to be executed, the protection level is thatof the file's owner, not the executor. To see how it works, suppose Tom owns a file andallows Ann to execute it with suid. When Ann executes the file, she has the protectionrights of Tom, not of herself.

This peculiar-sounding permission has a useful application. It permits a user toestablish data files to which access is allowed only through specified procedures.

For example, suppose you want to establish a computerized dating service thatmanipulates a database of people available on particular nights. Sue might be interestedin a date for Saturday, but she might have already refused a request from Jeff, saying shehad other plans. Sue instructs the service not to reveal to Jeff that she is available. To usethe service, Sue, Jeff, and others must be able to read the file and write to it (at leastindirectly) to determine who is available or to post their availability. But if Jeff can readthe file directly, he would find that Sue has lied. Therefore, your dating service must

force Sue and Jeff (and all others) to access this file only through an access program thatwould screen the data Jeff obtains. But if the file access is limited to read and write byyou as its owner, Sue and Jeff will never be able to enter data into it.

The solution is the Unix SUID protection. You create the database file, givingonly you access permission. You also write the program that is to access the database,and save it with the SUID protection. Then, when Jeff executes your program, hetemporarily acquires your access permission, but only during execution of the program.


15/25

Jeff never has direct access to the file because your program will do the actual file access.When Jeff exits from your program, he regains his own access rights and loses yours.Thus, your program can access the file, but the program must display to Jeff only the dataJeff is allowed to see.

This mechanism is convenient for system functions that general users should beable to perform only in a prescribed way. For example, only the system should be able tomodify the file of users' passwords, but individual users should be able to change theirown passwords any time they wish. With the SUID feature, a password change programcan be owned by the system, which will therefore have full access to the system passwordtable. The program to change passwords also has SUID protection so that when a normaluser executes it, the program can modify the password file in a carefully constrained wayon behalf of the user.

Per-Object and Per-User Protection

The primary limitation of these protection schemes is the ability to createmeaningful groups of related users who should have similar access to related objects. Theaccess control lists or access control matrices described earlier provide very flexibleprotection. Their disadvantage is for the user who wants to allow access to many usersand to many different data sets; such a user must still specify each data set to be accessedby each user. As a new user is added, that user's special access rights must be specifiedby all appropriate users.

User Authentication

***IMP***

a. Introductionb. Use of passwordsc. Attacks on passwordsd. Password selection criteriae. One-time passwords (challenge-response systems)f. The authentication processg. Authentication other than passwordsh. Conclusions

An operating system bases much of its protection on knowing who a user of thesystem is. In real-life situations, people commonly ask for identification from people theydo not know: A bank employee may ask for a driver's license before cashing a check,library employees may require some identification before charging out books, andimmigration officials ask for passports as proof of identity. In-person identification isusually easier than remote identification. For instance, some universities do not reportgrades over the telephone because the office workers do not necessarily know the


16/25

students calling. However, a professor who recognizes the voice of a certain student canrelease that student's grades. Over time, organizations and systems have developed meansof authentication, using documents, voice recognition, fingerprint and retina matching,and other trusted means of identification.

In computing, the choices are more limited and the possibilities less secure.Anyone can attempt to log in to a computing system. Unlike the professor whorecognizes a student's voice, the computer cannot recognize electrical signals from oneperson as being any different from those of anyone else. Thus, most computingauthentication systems must be based on some knowledge shared only by the computingsystem and the user.

Authentication mechanisms use any of three qualities to confirm a user's identity.

1. Something the user knows . Passwords, PIN numbers, passphrases, a secrethandshake, and mother's maiden name are examples of what a user may know.

2. Something the user has. Identity badges, physical keys, a driver's license, or auniform are common examples of things people have that make themrecognizable.

3. Something the user is. These authenticators, called biometrics, are based on aphysical characteristic of the user, such as a fingerprint, the pattern of a person'svoice, or a face (picture). These authentication methods are old (we recognizefriends in person by their faces or on a telephone by their voices) but are juststarting to be used in computer authentications.

***IMP***

I&A can be based on:1) What entity knows passwords

E.g., simple password, challenge-response authentication

2)What entity is biometricsE.g., fingerprints, retinal characteristics

3) What entity has - access tokensE.g., badges, smart cards

4) Where entity is locationE.g., in the accounting department

Any combinations of the above - hybrid approaches


17/25

Passwords as Authenticators

The most common authentication mechanism for user to operating system is apassword, a "word" known to computer and user. Although password protection seemsto offer a relatively secure system, human practice sometimes degrades its quality.

Use of Passwords

Passwords are mutually agreed-upon code words, assumed to be known only to the userand the system. In some cases a user chooses passwords; in other cases the systemassigns them. The length and format of the password also vary from one system toanother.

Even though they are widely used, passwords suffer from some difficulties of use:

Loss. Depending on how the passwords are implemented, it is possible that no

one will be able to replace a lost or forgotten password. The operators or systemadministrators can certainly intervene and unprotect or assign a particularpassword, but often they cannot determine what password a user has chosen; ifthe user loses the password, a new one must be assigned.

Use. Supplying a password for each access to a file can be inconvenient and timeconsuming.

Disclosure. If a password is disclosed to an unauthorized individual, the filebecomes immediately accessible. If the user then changes the password toreprotect the file, all the other legitimate users must be informed of the newpassword because their old password will fail.

Revocation. To revoke one user's access right to a file, someone must changethe password, thereby causing the same problems as disclosure.

Loose-Lipped Systems

So far the process seems secure, but in fact it has some vulnerabilities. To see why,consider the actions of a would-be intruder. Authentication is based on knowing the pair A complete outsider is presumed to know nothing of the system.Suppose the intruder attempts to access a system in the following manner. (In the

following examples, the system messages are in uppercase, and the user's responses are inlowercase.)

WELCOME TO THE XYZ COMPUTING SYSTEMS

ENTER USER NAME: adams

INVALID USER NAMEUNKNOWN USER

ENTER USER NAME:


18/25

We assumed that the intruder knew nothing of the system, but without having to domuch, the intruder found out that adams is not the name of an authorized user. Theintruder could try other common names, first names, and likely generic names such assystem or operator to build a list of authorized users.

An alternative arrangement of the login sequence is shown below.



ENTER PASSWORD: john

INVALID ACCESS

ENTER USER NAME:

This system notifies a user of a failure only after accepting both the user name and thepassword. The failure message should not indicate whether it is the user name orpassword that is unacceptable. In this way, the intruder does not know which failed.

These examples also gave a clue as to which computing system is being accessed. Thetrue outsider has no right to know that, and legitimate insiders already know what systemthey have accessed. In the example below, the user is given no information until thesystem is assured of the identity of the user.


ENTER PASSWORD: john

INVALID ACCESS


ENTER PASSWORD: johnq


***IMP***Attacks on passwords

Kinds of password attacks

i. Try allpossible pwds (exhaustive, brute force attack)ii. Try manyprobablepwds

iii. Try likely passwords pwdsiv. Search system list of pwdsv. Find pwds by exploiting indiscreet users (social engg)


19/25

Try allpossible pwds (exhaustive, brute force attack)

Try all possible

Try all possible = exhaustive attack / brute force attack

Approach: Try all possible character combinationsExample

Suppose: - only 26 chars (a-z) allowed in pwd- pwd length: 8 chars

nr_of_pwds = i=1 nr_of_i-char_pwd= i=1 26i = 269 1 5 * 1012

If attackers computer checks 1 pwd/s => 5* 1012 s = 5 mln s 2 months to check allpossible char combinations for a given pwd (max. exhaustive attack time)

With uniform distribution (neither good nor bad luck), expected successful attack time is= of max. exh. attack time (1 month)

Is the attack target worth such attackers investment?Might be e.g., a bank acct, credit card nr

In an exhaustive orbrute force attack, the attacker tries all possible passwords,usually in some automated fashion. Of course, the number of possible passwords dependson the implementation of the particular computing system. If we were to use a computerto create and try each password at a rate of checking one password per millisecond, it

would take on the order of 150 years to test all passwords. But if we can speed up thesearch to one password per microsecond, the work factor drops to about two months. Thisamount of time is reasonable if the reward is large. For instance, an intruder may try tobreak the password on a file of credit card numbers or bank account information.

But the break-in time can be made more tractable in a number of ways. Searchingfor a single particular password does not necessarily require all passwords to be tried; anintruder needs to try only until the correct password is identified. If the set of all possiblepasswords were evenly distributed, an intruder would likely need to try only half of thepassword space: the expected number of searches to find any particular password.However, an intruder can also use to advantage the fact that passwords are not evenly

distributed. Because a password has to be remembered, people tend to pick simplepasswords. This feature reduces the size of the password space.


20/25

Q) Find the required minimum password length s of passwords so that probabilityPof asuccessful attack is 0.5 over a 365-day guessing attack period?

Solution

We know that: P TG / N

P - probability of a successful attackT - number of time units [sec] during which guessing occursG - number of guesses per time unit [sec]N - number of possible passwords

P TG / N => N TG / P

Calculations:N TG / P =

= (365 days24hrs60min60s)104/0.5

= 6.311011

Choose password length s such that at least N passwords are possible, i.e. sj=1 96j N = 6.311011

(96 1-char words + 962 2-char words + 96s s-char words)

=> s 6

i.e., passwords must be at least 6 chars long

Try manyprobable pwds

Try manyprobable pwds (1)

Can reduce expected successful attack time by checking most probable charcombinations for a pwd first:

Check short pwds first

Check common words, etc. first

Example check short pwds first

People prefer short pwds => check pwds of length k

Assume 1 pwd checked per s (per ms in text p.213)

k=3: 261 + 262 + 263 = 18,278 possible pwds=> 18,278 s 18.3 ms to check all combinations

k=4: ... 475 ms 0.5 s k=5: ... 12,356 ms 12.4 s

************************************************************************

Penetrators searching for passwords realize these very human characteristics anduse them to their advantage. Therefore, penetrators try techniques that are likely to lead torapid success. If people prefer short passwords to long ones, the penetrator will plan totry all passwords but to try them in order by length. There are only 261 + 262 +


21/25

263=18,278 passwords of length 3 or less. At the assumed rate of one password permillisecond, all of these passwords can be checked in 18.278 seconds, hardly a challengewith a computer. Even expanding the tries to 4 or 5 characters raises the count only to475 seconds (about 8 minutes) or 12,356 seconds (about 3.5 hours), respectively.

This analysis assumes that people choose passwords such as vxlag and msms as

often as they pick enter and beer.

Try likely pwds************************************************************************

People are predictable in pwd selection

Attacker can restrict attack dictionary first to names of:family, pets, celebrities, sports stars, streets, projects,...

Example: 1979 study of pwds [Morris and Thompson]

Even single char pwds!

86% of pwds extremely simplistic! All could be discovered in a week even at 1 msec/pwd

checking rate

Study repeated in 1990 [Klein] and 1992 [Spafford] with similarly dismalresults!

Klein: 21% guessed in a week

Spafford: ~29% od pwds consisted oflowercase a-z only!

12 steps an attacker might try (start w/ most probable guesses)1) No password2) Same as user ID3) Users name or derived from it4) Common word list plus common names and patterns

Ex. common patterns: asdfg consecutive keyboard keys, aaaa5) Short college dictionary6) Complete English word list7) Common non-English language dictionaries8) Short college dictionary with capitalizations & substitutions

E.g. PaSsWoRd, pa$$w0rd

Substitutions include: a -> @, e -> 3, i/l -> 1, o -> 0, s -> $, ...9) Complete English with capitalization and substitutions10) Common non-English dictionaries with capitalization and substitutions11) Brute force, lowercase alphabetic characters12) Brute force, full character set


22/25

Search system list of pwds

************************************************************************

Search system list of pwds

System must keep list of passwords to authenticate logging users

Attacker may try to capture pwd list

Pwd lists:1) Plaintext system pwd file

2) Encrypted pwd filea. Conventional encryptionb. One-way encryption

Plaintext System Password List

To validate passwords, the system must have a way of comparing entries withactual passwords. Rather than trying to guess a user's password, an attacker may insteadtarget the system password file. Why guess when with one table you can determine allpasswords with total accuracy?

On some systems, the password list is a file, organized essentially as a two-column table of user IDs and corresponding passwords. This information is certainly tooobvious to leave out in the open. Various security approaches are used to conceal thistable from those who should not see it.

You might protect the table with strong access controls, limiting access to theoperating system. But even this tightening of control is looser than it should be, becausenot every operating system module needs or deserves access to this table. For example,the operating system scheduler, accounting routines, or storage manager have no need toknow the table's contents. Unfortunately, in some systems, there are n+1 known users: nregular users and the operating system. The operating system is not partitioned, so all itsmodules have access to all privileged information. This monolithic view of the operatingsystem implies that a user who exploits a flaw in one section of the operating system hasaccess to all the system's deepest secrets. A better approach is to limit table access to themodules that need access: the user authentication module and the parts associated withinstalling new users, for example.


23/25

If the table is stored in plain sight, an intruder can simply dump memory at aconvenient time to access it. Careful timing may enable a user to dump the contents of allof memory and, by exhaustive search, find values that look like the password table.

System backups can also be used to obtain the password table. To be able to

recover from system errors, system administrators periodically back up the file spaceonto some auxiliary medium for safe storage. In the unlikely event of a problem, the filesystem can be reloaded from a backup, with a loss only of changes made since the lastbackup. Backups often contain only file contents, with no protection mechanism tocontrol file access. (Physical security and access controls to the backups themselves aredepended on to provide security for the contents of backup media.) If a regular user canaccess the backups, even ones from several weeks, months, or years ago, the passwordtables stored in them may contain entries that are still valid.

Finally, the password file is a copy of a file stored on disk. Anyone with access tothe disk or anyone who can overcome file access restrictions can obtain the password file.

***IMP***Plaintext system pwd file

Protected w/ strong access controls

Only OS can access it

Better: onlysome OS modules that really need access to pwd listcan access it

Otherwise any OS penetration is pwd file penetration

Attackers ways od getting plaintext pwd files:

Memory dump and searching for pwd table

Get pwd table from system backups Backups often include no file protection security of

backups relies on physical security an access controls

Get pwd file by attacking disk

Encrypted Password File

There is an easy way to foil an intruder seeking passwords in plain sight: encryptthem. Frequently, the password list is hidden from view with conventional encryption orone-way ciphers.

With conventional encryption, either the entire password table is encrypted or justthe password column. When a user's password is received, the stored password isdecrypted, and the two are compared.

Even with encryption, there is still a slight exposure because for an instant theuser's password is available in plaintext in main memory. That is, the password isavailable to anyone who could obtain access to all of memory.


24/25

With one-way encryption, the password file can be stored in plain view. Forexample, the password table for the Unix operating system can be read by any user unlessspecial access controls have been installed. Because the contents are encrypted, backupcopies of the password table are no longer a problem.

There is always the possibility that two people might choose the same password,thus creating two identical entries in the password file. Even though the entries areencrypted, each user will know the plaintext equivalent. For instance, if Bill and Kathyboth choose their passwords on April 1, they might choose APRILFOOL as a password.Bill might read the password file and notice that the encrypted version of his password isthe same as Kathy's.

***IMP***

Encrypted pwd file

Two approaches:a. Conventional encryption / b. One-way encryption

a. Conventional encryption

Encrypts entire pwd tableOR

encrypts pwd column of pwd table

Pwd comparison procedure: When logging principal provides (cleartext) pwd, OS decrypts pwd from

pwd table

OS compares principals (clrtxt) pwd w/ decryptedpwd

Exposure 1: when decrypted pwd is for an instant in memory

Attacker who penetrates memory can get it

Exposure 2: attacker finding encryption key

One-way encryption (hashing)

Better solution - no pwd exposure in memory Pwd encrypted w/ one-way hash function and store

Pwd comparison procedure:

When logging principal provides (cleartext) pwd, OS hashes principalspwd (w/ one-way encryption)

Hash of principals pwd is compared with pwd hash from pwd table


25/25

Advantages of one-way encryption:

Pwd file can be stored in plain view

Backup files not a problem any more

Problem: If Alice and Bill selected the same pwd (e.g., Kalamazoo) and Bill readspwd file (stored in plain view), Bill learns Alices pwd

Solution:saltvalue is used to perturb hash fcn

Hashed value and salt stored in pwd table:

[Alice, saltAlice, E(pwdAlice+saltAlice)] stored for Alice

[Bill, saltBill, E(pwdBill+saltBill)] stored for Bill=> hashed Alices pwd hashed Bills pwd (even if pwdAlice = pwdBill)

When Principal X logs in, system gets saltX and calculates

E(pwdX+saltX)If result is the same as hash stored for X, X is authenticated

Unix+ circumvents this vulnerability by using a password extension, called the

salt. The salt is a 12-bit number formed from the system time and the process identifier.Thus, the salt is likely to be unique for each user, and it can be stored in plaintext in thepassword file. The salt is concatenated to Bill's password (pw) when he chooses it;E(pw+saltB) is stored for Bill, and his salt value is also stored. When Kathy chooses herpassword, the salt is different because the time or the process number is different. Callthis new one saltK. For her, E(pw+saltK) and saltK are stored. When either person tries to

log in, the system fetches the appropriate salt from the password table and combines thatwith the password before performing the encryption. The encrypted versions of (pw+salt)are very different for these two users. When Bill looks down the password list, theencrypted version of his password will not look at all like Kathy's.

Chapter 3 Os System Security

Documents

Transcript of Chapter 3 Os System Security