28 Protection in General Purpose operating system – controlled access

Hiteishi Diwanji

 

  • Forge access – user allowed to write in the file directory.
  • The operating system maintains all file directories, under commands from the owners of files.
  • The obvious rights to files are the common read, write, and execute familiar on many shared systems.
  • Right called owner , is possessed by the owner, permitting that user to grant and revoke access rights.
  • S has trouble remembering file contents from the name F . Another approach is to allow S to name F with any name unique to the directory of S . Then, F from A could be called Q to S
  • S may have forgotten that Q is F from A, and so S requests access again from A for F . But by now A may have more trust in S , so A transfers F with greater rights than before.
  • One subject, S , may have two distinct sets of access rights to F , one under the name Q and one under the name F .
  • Allowing pseudonyms leads to multiple permissions that are not necessarily consistent.
  • The directory approach is probably too simple for most object protection situations.

Access Control List

  • The access control list is the list for each object, and the list shows all subjects who should have access to the object and what their access is.
  • This approach differs from the directory list because there is one access control list per object ; a directory is created for each subject.
  • The Multics operating system used a form of access control list in which each user belonged to three protection classes: a user , a group , and a compartment . The user designation identified a specific subject, and the group designation brought together subjects who had a common interest, such as coworkers on a project.
  • The compartment confined an untrusted object; a program executing in one compartment could not access objects in another compartment without specific permission.
  • The compartment was also a way to collect objects that were related , such as all files for a single project.
  • The Multics operating system used a form of access control list in which each user belonged to three protection classes: a user , a group , and a compartment . The user designation identified a specific subject, and the group designation brought together subjects who had a common interest, such as coworkers on a project.
  • The compartment confined an untrusted object; a program executing in one compartment could not access objects in another compartment without specific permission.
  • The compartment was also a way to collect objects that were related , such as all files for a single project.
  • An access control matrix , a table in which each row represents a subject, each column represents an object, and each entry is the set of access rights for that subject to that object.
  • The access control matrix is sparse (meaning that most cells are empty): Most subjects do not have access rights to most objects.
  • The access matrix can be represented as a list of triples, having the form <subject, object, rights >. Searching a large number of these triples is inefficient enough that this implementation is seldom used.

 

BIBLI TEMP F HELP.TXT C_COMP LINKER SYS_CL PRINTE
OG OCK R
USER A ORW ORW ORW R X X R W

 

 

Capability

  • A capability is a ticket giving permission to a subject to have a certain type of access to an object.
  • For the capability to offer solid protection, the ticket must be unforgeable.
  • To make it unforgeable, do not give ticket directly to the user. Instead, the operating system holds all tickets on behalf of the users. The operating system returns to the user a pointer to an operating system data structure, which also links to the user.
  • A capability can be created only by a specific request from a user to the operating system.
  • Each capability also identifies the allowable accesses.
  • A capability is a ticket giving permission to a subject to have a certain type of access to an object.
  • For the capability to offer solid protection, the ticket must be unforgeable.
  • To make it unforgeable, do not give ticket directly to the user. Instead, the operating system holds all tickets on behalf of the users. The operating system returns to the user a pointer to an operating system data structure, which also links to the user.
  • A capability can be created only by a specific request from a user to the operating system.
  • Each capability also identifies the allowable accesses.
  • Capabilities can be encrypted under a key available only to the access control mechanism. If the encrypted capability contains the identity of its rightful owner, user A cannot copy the capability and give it to user B.
  • One possible access right to an object is transfer or propagate . A subject having this right can pass copies of capabilities to other subjects.
  • In this instance, process A can pass a copy of a capability to B, who can then pass a copy to C. B can prevent further distribution of the capability (and therefore prevent further dissemination of the access right) by omitting the transfer right from the rights passed in the capability to C. B might still pass certain access rights to C , but not the right to propagate access rights to other subjects.
  • As a process executes, it operates in a domain or local name space . The domain is the collection of objects to which the process has access. A domain for a user at a given time might include some programs, files, data segments, and I/O devices such as a printer and a terminal.
  • As execution continues, the process may call a subprocedure, passing some of the objects to which it has access as arguments to the subprocedure.
  • The domain of the subprocedure is not necessarily the same as that of its calling procedure; in fact, a calling procedure may pass only some of its objects to the subprocedure, and the subprocedure may have access rights to other objects not accessible to the calling procedure.
  • The caller may also pass only some of its access rights for the objects it passes to the subprocedure. For example, a procedure might pass to a subprocedure the right to read but not modify a particular data value.
  • Because each capability identifies a single object in a domain, the collection of capabilities defines the domain. When a process calls a subprocedure and passes certain objects to the subprocedure, the operating system forms a stack of all the capabilities of the current procedure. The operating system then creates new capabilities for the subprocedure.

Passing Objects to a Subject.

 

  • capabilities keep track of the access rights of subjects to objects during execution.
  • The capabilities can be maintained in table, such as an access control matrix or an access control list. Each time a process seeks to use a new object, the operating system examines the master list of objects and subjects to determine whether the object is accessible. If so, the operating system creates a capability for that object.
  • Capabilities must be stored in memory inaccessible to normal users. One way of accomplishing this is to store capabilities in segments not pointed at by the user’s segment table or to enclose them in protected memory as from a pair of base/bounds registers. Another approach is to use a tagged architecture machine to identify capabilities as structures requiring protection.
  • During execution, only the capabilities of objects that have been accessed by the current process are kept readily available. This restriction improves the speed with which access to an object can be checked.
  • Capabilities can be revoked. When an issuing subject revokes a capability, no further access under the revoked capability should be permitted. A capability table can contain pointers to the active capabilities spawned under it so that the operating system can trace what access rights should be deleted if a capability is revoked. A similar problem is deleting capabilities for users who are no longer active.

Procedure-Oriented Access Control

  • In procedure-oriented protection, a procedure controls access to objects.
  • Procedures can ensure that accesses to an object be made through a trusted interface.
  • For example, neither users nor general operating system routines might be allowed direct access to the table of valid users.
  • The only accesses allowed might be through three procedures: one to add a user, one to delete a user, and one to check whether a particular name corresponds to a valid user.
  • Procedure-oriented protection implements the principle of information hiding.
  • This is inefficient. There can be no simple, fast access, for frequently used objects.

File Protection Mechanisms

  • All or None Protection
  • In the original IBM OS operating systems, files were by default public.
  • Any user could read, modify, or delete a file belonging to any other user.
  • Instead of software- or hardware-based protection, the principal protection involved trust combined with ignorance.

Limitation of all or none protection

  • Lack of trust .
  • All or nothing
  •   Rise of timesharing
  •   Complexity
  •   File listings .

Group Protection

 

•      There are three classes: the user, a trusted working group associated with the user, and the rest of the users.

•      All authorized users are separated into groups.

•      The basis for group membership is need to share . The group members have some common interest and therefore are assumed to have files to share with the other group members.

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

•      The choices for access rights are a limited set, such as {read, write, execute, delete}. For a particular file, a user might declare read-only access to the general world, read and write access to the group, and all rights to the user.

•      This approach would be suitable for a paper being developed by a group, whereby the different members of the group might modify sections being written within the group. The paper itself should be available for people outside the group to review but not change.

•      advantage of the group protection approach

•Ease of implementation.

•      A user is recognized by two identifiers : a user ID and a group ID.

These identifiers are stored in the file directory entry for each file and are obtained by the operating system when a user logs in. Therefore, the operating system can easily check whether a proposed access to a file is requested from someone whose group ID matches the group ID for the file to be accessed.

 

Group Protection – difficulties

•      Multiple personalities – certain people might obtain multiple accounts. A single person can be only one user at a time. For example, Tom obtains two accounts, thereby becoming Tom1 in a group with Ann and Tom2 in a group with Bill. Tom1 is not in the same group as Tom2, so any files, programs, or aids developed under the Tom1 account can be available to Tom2 only if they are available to the entire world. Multiple personalities lead to a proliferation of accounts, redundant files, limited protection for files of general interest, and inconvenience to users.

 

•  All groups . To avoid multiple personalities, the system administrator may decide that Tom should have access to all his files any time he is active. This solution puts the responsibility on Tom to control with whom he shares what things. For example, he may be in Group1 with Ann and Group2 with Bill. He creates a Group1 file to share with Ann. But if he is active in Group2 the next time he is logged in, he still sees the Group1 file and may not realize that it is not accessible to Bill, too. Limited sharing . Files can be shared only within groups or with the world.

 

Single permission

 

Associate permission with a single file.

 

Single permission- Password or Other Token

 

•      Password protection to file protection by allowing a user to assign a password to a file.

•      User accesses are limited to those who can supply the correct password at the time the file is opened.

•      The password can be required for any access or only for modifications (write access).

 

Password access creates for a user the effect of having a different “group” for every file. However, file passwords suffer from difficulties similar to those of authentication passwords:

•      Loss . Depending on how the passwords are implemented, it is possible that no one will be able to replace a lost or forgotten password.

•      Use . Supplying a password for each access to a file can be inconvenient and time consuming.

•       Disclosure . If a password is disclosed to an unauthorized individual, the file becomes immediately accessible. If the user then changes the password to reprotect the file, all  the other legitimate users must be informed of the new password because their old password will fail.Revocation . To revoke one user’s access right to a file, someone must change the password, thereby causing the same problems as disclosure.

Temporary Acquired Permission

  • The Unix designers added a permission called set userid (suid) . If this protection is set for a file to be executed, the protection level is that of the file’s owner , not the executor .
  • Tom owns a file and allows Ann to execute it with suid . When Ann executes the file, she has the protection rights of Tom, not of herself.
  • It permits a user to establish data files to which access is allowed only through specified procedures.

Per-Object and Per-User Protection

  • limitation of these file protection schemes
  • – Create meaningful groups of related users with similar access to one or more data sets. The access control lists or access control matrices provide protection.
  • – Their disadvantage is for the user who wants to allow access to many users and to many different data sets; such a user must still specify each data set to be accessed by each user.
  • – As a new user is added, that user’s special access rights must be specified by all appropriate users.

User Authentication

 

Authentication mechanisms use any of three qualities to confirm a user’s identity:

  • Something the user knows . Passwords, PIN numbers , passphrases, a secret handshake, and mother’s maiden name are examples of what a user may know.Something the user hasIdentity badges, physical keys, a driver’s license, or a uniform are common examples of things people have that make them recognizable.
  • omething the user is .These authenticators, called biometrics, are based on a physical characteristic of the user, such as a fingerprint, the pattern of a person’s voice, or a face (picture).

User Authentication – Use of Passwords

  • common authentication mechanism for user to operating system is a password , a “word” known to computer and user.
  • Human practice sometimes degrades its quality.
  • A user enters some piece of identification, such as a name or an assigned user ID
  • this identification can be available to the public or easy to guess.
  • The system then requests a password from the user.
  • If the password matches that on file for the user, the user is authenticated and allowed access to the system.
  • If the password match fails, the system requests the password again, in case the user mistyped .

 

Loose-Lipped Systems

 

  • Authentication is based on knowing the
  • < name, password > pair.

WELCOME TO THE XYZ COMPUTING SYSTEMS

 

ENTER USER NAME: adams

 

INVALID USER NAMEUNKNOWN USER

 

ENTER USER NAME:

  • Intruder knew nothing of the system, but the intruder found out that adams is not the name of an authorized user.
  • The intruder could try other common names, first names, and likely generic names such as system or operator to build a list of authorized users.
  • An alternative arrangement of the login sequence is shown below.

WELCOME TO THE XYZ COMPUTING SYSTEMS          ENTER                  USER NAME:

 

adams

 

ENTER PASSWORD: john INVALID ACCESS

 

This system notifies a user of a failure only after accepting both the user name and the password. The failure message should not indicate whether it is the user name or password that is unacceptable. The intruder does not know which failed.

 

Additional Authentication Information

  • Limit users to certain terminals or certain times of access .
  • Problem with this system :

when a user legitimately needs to work overtime, or a person has to access the system while out of town on a business trip.

Exhaustive Attack

  • In an exhaustive or brute force attack , the attacker tries all possible passwords.
  • The number of possible passwords depends on the implementation of the particular computing system.
  • For example, if passwords are words consisting of the 26 characters AZ and can be of

any length from 1 to 8 characters , there are 26 1 passwords of 1 character,

 

26 2passwords of 2 characters, and 26 8 passwords of 8 characters. Therefore, the system as a whole has 26 1 + 26 2 + … + 26 8 = 26 9 1 5 * 10 12 or five million million possible passwords.

 

Probable Passwords

  • Penetrators searching for passwords study the human characteristics and use them to their advantage.
  • penetrators try techniques that are likely to lead to rapid success.
  • If people prefer short passwords to long ones, the penetrator will plan to try all passwords but to try them in order by length. There are only 26 1 + 26 2 + 26 3 = 18,278 passwords of length 3 or less.

Passwords Likely for a User

  • People typically choose personal passwords, such as the name of a spouse, a child, a brother or sister, a pet, a street name, or something memorable or familiar.

Plaintext System Password List

  • The password list is a file, organized essentially as a two-column table of user IDs and corresponding passwords.

Encrypted Password File

  • With conventional encryption, either the entire password table is encrypted or just the password column.
  • When a user’s password is received, the stored password is decrypted, and the two are compared.
  • If two people might choose the same password, thus creating two identical entries in the password file. Even though the entries are encrypted, each user will know the plaintext equivalent.
  • 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. the salt unique for each user, and it can be stored in plaintext in the password file. The salt is concatenated to user’s password ( pw ) when he chooses it

 

Indiscreet Users

  • People often tape a password to the side of a terminal, or write it on a card just inside the top desk drawer .
  • Users are afraid they will forget their passwords, or they cannot be bothered trying to remember them.
  • It is particularly tempting to write the passwords down when users have several accounts.
  • Users sharing work or data may also be tempted to share passwords. If someone needs a file, it is easier to say “my password is x ; get the file yourself” than to arrange to share the file.
  • This situation is a result of user laziness , but it may be brought about or exacerbated by a system that makes sharing inconvenient.

Password selection criteria

  • Use characters other than just AZ .
  • Choose long passwords .
  • Avoid actual names or words .
  • Choose an unlikely password .
  • Change the password regularly .
  • Don’t write it down .
  • Don’t tell anyone else .

One-Time Passwords

  • A one-time password is one that changes every time it is used.
  • f ( x ) = x + 1 . With this function, the system prompts with a value for x , and the user enters the value x + 1. Other similar possibilities are f ( x ) = 3 x 2 9 x + 2, f ( x) = p x , where p x is the x th prime number, or f ( x ) = d * h , where d is the date and h is the hour of the current time.
  • f ( x ) = r ( x ) . For this function, the receiver uses the argument as the seed for a random number generator (available to both the receiver and host). The user replies with the value of the first random number generated.
  • f ( a 1 a 2 a 3 a 4 a 5 a 6 ) = a 3 a 1 a 1 a 4 . With this function, the system provides a character string, which the user must transform in some predetermined manner.
  • f ( E ( x )) = E ( D ( E ( x )) + 1) . In this function, the computer sends an encrypted value, E ( x ). The user must decrypt the value, perform some mathematical function, and encrypt the result to return it to the system.

The Authentication Process

  • users occasionally mistype their passwords. A user who receives a message of INCORRECT LOGIN will carefully retype the login and gain access to the system. Even a user who is a terrible typist should be able to log in successfully in a few tries.
  • Some authentication procedures are intentionally slow. A legitimate user will not complain if the login process takes 5 or 10 seconds. To a penetrator who is trying an exhaustive search or a dictionary search, however, 5 or 10 seconds per trial makes this class of attack generally infeasible.
  • Someone who continually fails to log in may not be an authorized user. Systems commonly disconnect a user after a small number of failed logins, forcing the user to reestablish a connection with the system.
  • Stopping penetrators is more important than tolerating users’ mistakes. For example, some system administrators assume that all legitimate users can type their passwords correctly within three tries.
  • After three successive password failures, the account for that user is disabled and only the security administrator can reenable it.
  • This action identifies accounts that may be the target of attacks by penetrators.

Fixing Flaws in the Authentication Process

  • Password authentication assumes that anyone who knows a password is the user to whom the password belongs.
  • A second level of protection, including another round of passwords or a challenge-response interchange

ChallengeResponse Systems

  • In such an interchange, the system prompts the user for a reply that will be different each time the user logs in.
  • For example, the system might display a four-digit number, and the user would have to correctly enter a function such as the sum or product of the digits.
  • Each user is assigned a different challenge function to compute. Because there are many possible challenge functions, a penetrator who captures the user ID and password cannot necessarily infer the proper function.

Impersonation of Login

  • A programmer can easily write a program that displays the standard prompts for user ID and password, captures the pair entered, stores the pair in a file, displays SYSTEM ERROR; DISCONNECTED, and exits. This attack is a type of Trojan horse. The perpetrator sets it up, leaves the terminal unattended, and waits for an innocent victim to attempt a login. The nave victim may not even suspect that a security breach has occurred.
  • To foil this type of attack, the user should be sure the path to the system is reinitialized each time the system is used. On some systems, turning the terminal off and on again or pressing the BREAK key generates a clear signal to the computer to halt any running process for the terminal.

Authentication Other Than Passwords

 

  • Sophisticated authentication devices are available.
  • These devices include handprint detectors, voice recognizers, and identifiers of patterns in the retina.
  • Authentication with such devices uses unforgeable physical characteristics to authenticate users.
  • The devices are useful in very high security situations.

Suggested Reading:

  1. Cryptography and Network Security Principles and Practice by William Stallings, sixth Edition, PEARSON.
  2. Security in Computing by Charles Pfleeger & Shari Lawrence Pfleeger, fourth Edition, PEARSON.
  3. Network Security by Charlie Kaufman, Radia Perlman, Mike Speciner, second Edition, PHI.
  4. The Complete Reference – Network Security by Roberta Bragg, Mark Rhodes-Ousley & Keith Strassberg, Tata McGraw Hill
  5. Network Security Bible by Eric Cole, Ronald Krutz, James Conley, Wiley
  6. Hacking 6 Exposed by Stuart McClure, Joel Scambray & George Kurtz , Tata McGraw Hill .
  7. www.snort.org
  8. https://nmap.org