Module 2

1. OS Security: File systems often contain information that is highly valuable to their users. Protecting this information against unauthorized usage is therefore a major concern of all file systems. Various issues concerned with security and protection are given below: 1.1 The Security Environment: The terms Security and Protection are often used interchangeably. Security refers to the overall problem involved in preventing unauthorized reads or modifications, which include technical, managerial, legal, and political issues. Protection refers to the specific operating system mechanisms used to safeguard information in the computer. The two important facets of Security are Data Loss and Intruders. Data Loss is mainly caused by 1. Acts of God (fires, floods, earthquakes) 2. Hardware or Software errors (CPU malfunctions, unreadable disks or tapes, telecommunication errors, program bugs) 3. Human Errors (incorrect data entry, wrong tape or disk mounted, wrong program run, lost disk or tape). Intruders come in 2 varieties: 1. Passive Intruders who read files they are not authorized to read. 2. Active Intruders who make unauthorized changes to data. Another aspect of Security problem is Privacy: protecting individuals from misuse of information about them. 1.2 The Internet Worm: The greatest computer security violation began in the form of a worm program. A WORM is a self replicating program that replicates itself in seconds on every machine it could gain access to. 1.3 Generic Security Attacks: Viruses: A Virus is a program fragment that is attached to a legitimate program with the intention of infecting other programs. It differs from a worm only in that a virus piggybacks on an existing program, whereas a worm is a complete program in itself. Viruses and worms both attempt to spread themselves and both can do severe damage.

In addition to just infecting other programs, a virus can erase, modify, or encrypt files. It is also possible for a virus to infect the hard disks boot sector, making it impossible to boot the computer. Virus problems are easier to prevent than to cure. The safest course is only to buy shrink-wrapped software from respectable stores and to avoid uploading free software from bulletin boards or getting pirated copies on floppy disk. 1.4 Design Principles for Security: Viruses mostly occur on desktop systems. On larger systems other problems occur and other methods are needed for dealing with them. Some general principles that can be used as a guide to designing secure systems have been identified by Saltzer and Schroeder. They are: i. The system design should be public - Assuming that the intruder will not know how the system works serves only to delude the designers.

ii. The default should be no access - Errors in which legitimate access is refused will be reported much faster than errors in which unauthorized access is allowed. iii. Check for current authority - Many systems check for permission when a file is opened, and not afterward. This means that a user who opens the file, and keeps it open for weeks, will continue to have access, even if the owner has long since changed the file protection. iv. Give each process the least privilege possible - If an editor has only the access the file to be edited, editors with Trojan horses will not be able to do much damage. v. The protection mechanism should be simple, uniform and built in to the lowest layers of the system - Trying to retrofit security to an existing insecure system is nearly impossible. Security is not an add-on feature. vi. The Scheme chosen must be psychologically acceptable - If users feel that protecting their files is too much work, they just will not do it.

1.5 User Authentication: The problem of identifying users when they log in is called user authentication. Most authentication methods are based on identifying something the user knows, something the user has, or something the user is. Passwords: The most widely used form of authentication is to require the user to type a password. Password protection is easy to implement and easy to understand. Password protection is also easy to defeat. Guessing a user name and password combination constitutes the break-in all the time virtually.

Some computers require users to change their passwords regularly, to limit the damage done if a password leaks out. The most extreme form of this approach is the One-Time Password. When one-time passwords are used, the user gets a book containing a list of passwords. Each login uses the next password in the list. If an intruder ever discovers a password, it wont be of any good, since next time a different password must be used. It is suggested that the user try to avoid losing the password book. Another variation is Challenge-Response. When this is used, the user picks an algorithm when signing up as a user, for example 2x. When the user logs in, the computer types an argument, say 7, in which case the user types 14. The algorithm can be different on different days of the weeks, at different times, from different terminals, and so on. Physical Identification: This approach checks whether the user has some item, normally a plastic card with a magnetic stripe on it. The card is inserted into the terminal, which then checks to see whose card is it. This method can be combined with a password, so a user can only log in if he has the card and knows the password. Automated cash-dispensing machines usually work this way. To measure physical characteristics that are hard to forge is another method. For example, a fingerprint or a voiceprint reader in the terminal could identify the users identity. Another technique is Signature Analysis, where the user signs his name with a special pen connected to the terminal, and the computer compares it to a known specimen stored on line. Even better is not to compare the signature, but compare the pen motions while writing it. A good forger may be able to copy the signature, but will not have a clue as to the exact order in which the strokes were made. In Finger Length Analysis, each terminal has a device similar to the palm. The user inserts his hands into it, and the length of all his fingers is measured and checked against the database.

2. Protection Mechanisms Some of the detailed technical ways that are used in operating systems to protect files and other things are discussed here. All these techniques clearly distinguish between policy and mechanism. POLICY involves whose data are to be protected from whom and MECHANISM involves how the system enforces the policy. 2.1 Protection Domains A computer system contains many OBJECTS that need to be protected. These objects can be hardware such as CPUs, memory segments, terminals, disk drives or printers or they can be Software such as processes, files, data bases, or semaphores. Each object has a unique name by which it is referenced and a set of operations that can be carried out on it. READ and WRITE operations appropriate to a file; UP and DOWN make sense on semaphore. Protection mechanism is a way used to prohibit processes from accessing objects that they are not authorized to access. This mechanism should also restrict processes to a subset of the legal operations when that is needed. For example process A may be entitled to read, but not write, file F.

A DOMAIN is a set of (object, rights) pairs. Each pair specifies an object and some subset of the operations that can be performed on it. A RIGHT here means permission to perform one of the operations.

Domain 1

Domain 2

Domain 3

File1[R] File2 [RW]

File3[R] File4[RWX] Printer1[W] File5[RW]

File6[RWX] Plotter2[W]

Fig: Three Production Domains. The above figure depicts 3 domains, showing the objects in each domain and the rights [Read, Write, eXecute] available on each object. Printer1 is in 2 domains at the same time. It is also possible for the same object to be in multiple domains, with different rights in each domain. At every instant of time, each process runs in some protection domain. In other words, there is some collection of objects it can access, and for each object it has some set of rights. Processes can also switch from domain to domain during execution. The rules for domain switching are highly system dependent. Example: In UNIX, the domain of a process is defined by its uid and gid. Given any (uid, gid) combination, it is possible to make a complete list of objects (files, including I/O devices represented by special files, etc) that can be accessed, and whether they can be accessed for reading, writing, or executing. 2 processes with same (uid, gid) combination will have access to exactly the same set of objects. Processes with different (uid, gid) values will have access to a different set of files, although there will be considerable overlap in most cases. Each process in UNIX has 2 halves: the USER part and the KERNEL part. When the process does a system call, it switches from the user part to the kernel part. The kernel part has access to a different set of objects from the user part. For example, the kernel can access all the pages in physical memory, the entire disk, and all the other protected resources. Thus, a system call causes a domain switch.

Protection Matrix: This is used to know how the system keeps track of which object belongs to which domain. Imagine a large matrix, with the rows being the domains and the columns being the objects. Each box lists the rights, if any, that the domain contains for the object.

The matrix for the first figure (3 protection domains) is shown below:

Domain

Object

File 1 1 Read

File 2 Read Write

File 3

File 4

File 5

File 6

Printer 1

Plotter 2

Read

Read Write Execute

Read Write Read Write Execute

Write

Write

Write

Figure: A Protection Matrix. Given this matrix and the current domain number, the system can tell if an access to given object in a particular way from a specified domain is allowed. Domain switching itself can be easily included in the matrix model by realizing that a domain is itself an object, with the operation ENTERS. The figure below shows the matrix of the above figure again, only now with the three domains as objects themselves. Processes in domain 1 can switch to domain 2, but once there, they cannot go back.

Domain

Object

File 1 1 R

File 2 R W

File 3

File 4

File 5

File 6

Printer 1

Plotter 2

D1

D2 Enter

D3

R W X

R W R W X

Figure: A protection matrix with domains as objects.

Storing very large and sparse matrices are rarely done in practice. Most domains have no access at all to most objects, so storing a big, empty matrix is a waste of disk space. 2 methods used practically are storing the matrix by rows or by columns, and then storing only the nonempty elements. Storing by columns: It consists of associating with each object an (ordered) list containing all the domains that may access the object. This list is called the Access Control List or ACL. As only the nonempty entries of the matrix are stored, the total storage required for all the ACLs combined is much less than would be needed for the whole matrix. The owner of an object can change its ACL at any time, thus making it easy to prohibit accesses that were previously allowed. The only problem is that changing the ACL will probably not affect any users who are currently using the object (e.g., have the files open). Storing by rows: It is the slicing up the matrix by rows. Here, associated with each process is a list of object that may be accessed, along with an indication of which operations are permitted on each (its domain). This list is called a Capability List or C-lists, and the individual items on it are called Capabilities. A typical capability list is shown below: Type Rights Object File R-Pointer to File3 File RWX Pointer to File4 File RW- Pointer to File5 Printer -WPointer to Printer1

O 1 2 3

Each capability has a: Type field ------> specifies what kind of object it is, Rights field-----> which is a bit map indicating which of the legal operations on this type of object are permitted. Object field-----> which is a pointer to the object itself. C-lists are themselves objects, and may be pointed from other C-lists, thus facilitating sharing of sub domains. Capabilities are often referred to by their position in the capability list. C-lists must be protected from user tampering. 3 methods have been proposed to protect them: 1. The first way requires a tagged architecture, a hardware design in which each memory word has an extra (or tag) bit that tells whether the word contains a capability or not. The tag bit is not used by arithmetic, comparison, or similar ordinary instructions and it can be modified only by programs running in the kernel mode (i.e., the operating system). 2. The second way is to keep the C-list inside the operating system, and just have processes refer to capabilities by their slot number. 3. The third way is to keep the C-list in user space, but encrypt each capability with a secret key unknown to the user. This approach is particularly suited to distributed systems.

In addition to the specific object-dependent rights, such as read and execute, capabilities usually have generic rights which are applicable to all objects. Examples of generic rights are: a. COPY CAPABILITY: create a new capability for the same object. b. COPY OBJECT: create a duplicate object with a new capability. c. REMOVE CAPABILITY: delete an entry from the C-list; object unaffected. d. DESTROY OBJECT: permanently remove an object and a capability. Many capability systems are organized as a collection of modules, with type manager modules for each type of object. Requests to perform operations on a file are sent to the file manager, whereas requests to do something with a mailbox go to the mailbox manager. These requests are accompanied by the relevant capability. A problem arises here, because the type manager module is just an ordinary program, after all. The owner of a file capability can perform only some of the operations on the file, but cannot get at its internal representation. It is necessary that the type manager module be able to do more with the capability than an ordinary process. Hydra solved this problem by a technique called rights amplification, in which type managers were given a rights template that gave them more rights to an object than the capability itself allowed. In Capability systems, revoking access to an object is quite difficult. It is hard for the system to find all the outstanding capabilities for any object to take them back, since they may be stored in C-lists all over the disk. One approach is to have each capability point to an indirect object, rather than to the object itself. By having the indirect object point to the real object, the system can always break that connection, thus invalidating the capabilities. (When a capability to the indirect object is later presented to the system, the user will discover that the indirect object is now pointing to a null object.) Amoeba uses another scheme to achieve revocation. Each object contains a long random number, which is also present in the capability. When a capability is presented for use, the two are compared. Only if they agree, is the operation allowed. The owner of an object can request that the random number in the object be changed, thus invalidating existing capabilities. Neither scheme allows selective revocation, that is, taking back only ones permission, but nobody elses.

2.3. Protection Models Protection matrices are not static. They frequently change as new objects are created, old objects are destroyed, and owners decide to increase or restrict the set of users for their objects. There are 6 primitive operations on the protection matrix that can be used as a base to model any protection system. These operations are: CREATE OBJECT, DELETE OBJECT, CREATE DOMAIN, DELETE DOMAIN, INSERT RIGHT, and REMOVE RIGHT. The 2 latter primitives insert and remove rights from specific matrix elements. These 6 primitives can be combined into protection commands. User programs execute these protection commands to change the matrix. They may not execute the primitives directly. At any instant, the matrix determines what a process in any domain can do, not what it is authorized to do. The matrix is what is enforced by the system; authorization has to do with management policy.

Example: Consider the simple system below, where domains correspond to user. Objects Compiler Eric Henry Robert Read Execute Read Execute Read Execute Mailbox7 Secret Eric Read Write Read Write Henry Robert Objects Compiler Read Execute Read Execute Read Execute Mailbox7 Secret

Read Write Read Read Write

Fig: (a) An authorized state.

(b) An unauthorized state.

In the figure (a) the intended protection policy is seen: Henry can read and write mailbox7, Robert can read and write secret, and all the 3 can read and execute compiler. If Robert found a way to issue commands and have the matrix changed to figure (b); then he can access mailbox7, something he is not authorized to have. If he tries to read it, the operating system will carry out his request because it does not know that the state is an unauthorized one. The set of all possible matrices can be partitioned into 2 disjoint sets: a. The set of all authorized states, and b. The set of all unauthorized states. The security policy enforced by the protection commands has 2 rules: 1. No process may read any object whose level is higher that its own, but it may freely read objects at a lower level or at its own level. A secret process may read confidential objects, but not top secret ones. 2. No process may write information into any object whose level is lower than its own. A secret process may write in a top secret file but not in a confidential one. 2.4 Covert Channels To make formal models for protection systems is much futile. Even in a system that has been rigorously proven to be absolutely secure, leaking information between processes that in theory cannot communicate at all is relatively straightforward. Lampson proposed a model which involves 3 processes, and is primarily applicable to large time sharing systems. The first process is a Client, which wants some work performed by the second one, the Server. The client and the server do not entirely trust each other. The third process is the Collaborator, which is conspiring with the server to indeed steal the clients confidential data. The collaborator and server are typically owned by the same person. These 3 processes are shown in the figure below:

Client

Server

Collaborator

Encapsulated server

Covert Channel Kernel Kernel

The object here is to design a system in which it is impossible for the server to leak to the collaborator the information that it has legitimately received from the client. Lampson called this the confinement problem. From the system designers point of view, the goal is to encapsulate or confine the server in such a way that it cannot communicate with the collaborator by writing into a file to which the collaborator has read access. It is also necessary to ensure that the server cannot communicate with the collaborator by using the systems inter-process communication mechanism. But more subtle communication channels may be available. For example, the server can try to communicate a binary bit stream as follows. To send a 1 bit, it computes as hard as it can for a fixed interval of time. To send a 0 bit, it goes to sleep for the same length of time. The collaborator can try to detect the bit stream by carefully monitoring its response time. In general, it will get better response time when the server is sending a 1. This communication channel is known as a covert channel. The covert channel is a noisy channel, containing a lot of extraneous information. But information can be reliably sent over a noisy channel by using an error-correcting code (e.g. a hamming code). The use of an error-correcting code reduces the already low bandwidth of the covert channel even more, but it still may be enough to leak substantial information. No protection model based on a matrix of objects and domains can prevent this kind of leakage. Modulating the CPU usage is not only the covert channel. The paging rate can also be modulated (many page faults for a 1, no page faults for a 0). Almost any way of degrading system performance in a clocked way is a candidate. If the system provides a way of locking files, then the server can lock some file to indicate a 1, and unlock it to indicate a 0. It may be possible to detect the status of a lock even on a file that cannot be accessed. Acquiring and releasing dedicated resources (tape drives, plotters, etc) can also be used for signaling. The server acquires the resource to send a 1 and releases it to send a 0. But, even finding all the covert channels, let alone blocking them, is extremely difficult.

3. DAC (Discretionary Access Control) One of the features of the Criteria that are required of a secure system is the enforcement of discretionary access control (DAC). DAC is a means of restricting access to objects based on the identity of subjects and/or groups to which they belong. The controls are discretionary in the sense that a user or process given discretionary access to information is capable of passing that information along to another subject. Discretionary control is the most common type of access control mechanism implemented in computer systems today. The basis of this kind of security is that an individual user, or program operating on the user's behalf, is allowed to specify explicitly the types of access other users (or programs executing on their behalf) may have to information under the user's control. Discretionary security differs from mandatory security in that it implements the access control decisions of the user. Mandatory controls are driven by the results of a comparison between the user's trust level or clearance and the sensitivity designation of the information. Discretionary controls are not a replacement for mandatory controls. In any environment in which information is protected, discretionary security provides for a finer granularity of control within the overall constraints of the mandatory policy. Both discretionary and mandatory controls can be used to implement an access control policy to handle multiple categories or types of information, such as proprietary, financial, personnel or classified information. Such information can be assigned different sensitivity designations and those designations enforced by the mandatory controls. Discretionary controls can give a user the discretion to specify the types of access other users may have to information under the user's control, consistent with the overriding mandatory policy restrictions. In a classified environment, no person may have access to classified information unless: (a) that person has been determined to be trustworthy, i.e., granted a personnel security clearance - MANDATORY, and (b) access is necessary for the performance of official duties, i.e., determined to have need-to-know - DISCRETIONARY. The discretionary security control objective is: Security policies defined for systems that are used to process classified or other sensitive information must include provisions for the enforcement of discretionary access control rules. That is, they must include a consistent set of rules for controlling and limiting access based on identified users who have been determined to have need-to-know for the information. DEFINITIONS Discretionary Access Control (DAC)-The Criteria defines discretionary access control as: A means of restricting access to objects based on the identity of subjects and/or groups to which they belong. The controls are discretionary in the sense that a subject with certain access permission is capable of passing that permission (perhaps indirectly) on to any other subject. DAC controls are used to restrict a user's access to protected objects on the system. The user may also be restricted to a subset of the possible access types available for those protected objects. Access types are the operations a user may perform on a particular object (e.g., read, write, execute). Typically, for each object, a particular

user or set of users has the authority to distribute and revoke access to that object. Users may grant or rescind access to the objects they control based on "need to know" or "whom do I like" or other rules. DAC mechanisms control access based entirely on the identities of users and objects. The identity of the users and objects is the key to discretionary access control. This concept is relatively straightforward in that the access control matrix contains the names of users on the rows and the names of objects on the columns. Regardless of how the matrix is represented in memory, whether by rows or by columns, the names of the users and objects must be used in the representation. For example, in a row-based representation an entry might read the equivalent of KIM can access KIMSFILE and DONSFILE". In a column based representation, one might find the equivalent of "DONSFILE can be accessed by DON, JOE and KIM". AN INHERENT DEFICIENCY IN DISCRETIONARY ACCESS CONTROL A FUNDAMENTAL FLAW IN DISCRETIONARY ACCESS CONTROL Discretionary access control mechanisms restrict access to objects based solely on the identity of subjects who are trying to access them. This basic principle of discretionary access control contains a fundamental flaw that makes it vulnerable to Trojan horses. On most systems, any program which runs on behalf of a user inherits the DAC access rights of that user. An example of the workings of a Trojan horse will illustrate how most DAC mechanisms are vulnerable. AN EXAMPLE OF A TROJAN HORSE Consider a system where an access control list mechanism is used to implement discretionary access control. There are two users on this particular system: an honest user, DOE; and a dishonest user, DRAKE. Doe has a data file which contains highly sensitive data; this file is known as DOESFILE. He has diligently set the ACL to allow only himself to read the file. No other users are authorized to access the file. Doe is confident that no one but himself will be able to access his data file. Drake is determined to gain access to DOESFILE. He has legitimate access to the system which allows him to implement a useful utility program. In this utility Drake embeds a covert function to read DOESFILE and copy the contents into a file in Drakes address space called DRAKESFILE. DRAKESFILE has an ACL associated with it that allows processes executing on Does behalf to write to it, while allowing Drakes processes to read it. Drake induces Doe to execute his utility program by telling him how useful and efficient it is. Drake is careful not to tell Doe about the covert function (Trojan horse) that is resident in the utility program. Doe executes the corrupted program and it appears to perform perfectly. However, while it is operating on Doe's behalf, it assumes his identity and thus his access rights to DOESFILE. At this time it copies the contents of DOESFILE to DRAKESFILE. This copying takes place completely within the constraints of the DAC mechanism, and Doe is unaware of what is happening. This example should make clear the danger of Trojan horse attacks and the inadequacy of most DAC mechanisms to protect against such attacks. It should be noted that an elaborate DAC mechanism may provide illusory security to users who are unaware of its vulnerability to Trojan horse attacks. Configuration management, testing, and trusted distribution should ensure that software produced by the computer system manufacturer does not contain Trojan horses, especially if the system has a high EPL rating. However, software from other

sources does not come with these assurances. In very high threat environments, it is wise to assume that unevaluated software does contain Trojan horses. This assumption dictates that discretionary access control not be used as the sole protection mechanism in high threat environments. The Trojan horse threat can be reduced in systems that implement many domains or dynamic small domains for each process. In most systems today, with only user and supervisor domains, all of the user's objects are available to a process running on that user's behalf. If domains were created dynamically for each process, with only the necessary objects available, in that domain (implementing the least privilege principle), then a Trojan horse would be limited to accessing only those objects within the domain. A reference monitor which implements a mandatory security policy which includes the *-property would provide robust protection against Trojan horse attacks. The mandatory access control implementation would prevent the Trojan horse from disclosing the information to a user who is not permitted access to the information under the mandatory access rules. The computer system implements a mandatory security policy with two hierarchical sensitivity levels. For the sake of simplicity, the levels are called sensitive and non-sensitive. DOE operates at the sensitive level, and DOESFILE is sensitive. DRAKE is not authorized to access sensitive data, so he operates at the non-sensitive level. DRAKE is only allowed to read non-sensitive files, so DRAKESFILE is nonsensitive. As before, Drakes Trojan horse program is executed by DOE. The program takes on the sensitivity level and the identity of DOE. Within the constraints of the mandatory and the discretionary security policies, the program reads DOESFILE. However, when the Trojan horse tries to write the sensitive data to DRAKESFILE, the reference monitor disallows the operation. Since the Trojan horse is no w executing at the sensitive level, the program cannot be allowed to write to a non-sensitive file. That would be a violation of the *-property. AN OVERVIEW OF DAC MECHANISMS Implementing a complete DAC system requires retaining the information that is represented by the access control matrix model in some form. An access control matrix has users represented on the rows and protected objects on the columns. The entries in the matrix describe what type of access each user has to each object. Current operating systems have attempted to represent that information using five basic mechanisms: 1. Capabilities 2. Profiles 3. Access Control Lists (ACLs) 4. Protection Bits 5. Passwords CAPABILITIES In a capability-based system, access to protected objects such as files is granted if the would- be accessor possesses a capability for the object. The capability is a protected identifier that both identifies the object and specifies the access rights to be allowed to the accessor who possesses the capability. Two fundamental properties of capabilities are that they may be passed from one accessor (subject) to another and that the accessor who possesses capabilities may not alter or fabricate capabilities without the mediation of the operating sys tem TCB. Capability-based systems provide dynamically changeable domains (name spaces) for processes to run in. Ability to access an object is demonstrated when a

process has a capability or ticket to the object. The capability also contains allowable access modes (e.g., read, write, execute). In some implementations, programs can contain capabilities or capabilities can be stored in files. They are protected by hardware and software mechanisms or by encryption. Capabilities can usually be passed along to other processes and can sometimes be increased or decreased in scope. A pure capability system includes the ability for users to pass the capability to other users. Because this ability is not controlled and capabilities can be stored, determining all the users who have access for a particular object generally is not possible. This makes a complete DAC implementation, including revocation, very difficult. (Revocation may not be an issue, however, since a user who has access to an object can make a copy of the information in another object. Revoking the user's access on the original object does not revoke access to the information contained in the user's copy. After revocation, however, changes can be made to the original object without the knowledge of revoked users.) Since capabilities implement dynamic domains they can ideally limit the objects accessible to any program. This would limit a Trojan horse's access to only the protected objects handed to it. At this time, few systems have been implemented with capabilities and very few, if any, have attempted to implement a complete DAC mechanism. Capabilities could be useful in enforcing the least privilege principle and providing dynamically changeable domains, making discretionary access controls less vulnerable to Trojan horse attacks. PROFILES Profiles which have been implemented in some form on several systems use a list of protected objects associated with each user. Since object names are not consistent or amenable to grouping, their size and number are difficult to reduce. If a user has access to many protected objects, the profile can get very large and difficult to manage. Also, all protected object names must be unique so full pathnames must be used. Creating, deleting and changing access to protected objects requires many operations since multiple users' profiles must be updated. Timely revocation of access to an object is very difficult unless the user's profile is automatically checked each time the object is accessed. Deleting an object may require some method of determining every user who has the object in his profile. In general, with profiles as with capabilities, answering the question of who has access to a protected object is very difficult. Since this is usually an important question in a secure system and more efficient mechanisms exist, profiles are not a recommended implementation of DAC. ACCESS CONTROL LISTS (ACLs) ACLs allow any particular user to be allowed or disallowed access to a particular protected object. They implement the access control matrix b y representing the columns as lists of users attached to the protected objects. The lists do not have to be excessively long if groups and wild cards (see below) are used. The use of groups raises the possibility of conflicts between group and individual user. As an example, the ACL entries "PAYROL rw" and "Jones.PAYROL r" appear to conflict, but can be resolved in the design of the DAC mechanism. The Apollo system has a multiple, hierarchical group mechanism. The ACL entry has the form userid.group.organization.node. As in Multics, if the ACL specifies access rights for the

user by user-id then group access rights are ignored. This allows a particular user to be excluded or restricted in access rights. In the Apollo, if a user is not on the ACL by user-id, but is a member of a group, those rights are used and organization and node memberships are not examined. Multiple group mechanisms add more complexity and may facilitate administrative control of a system, but do not affect the utility of a DAC mechanism. Access to ACLs should be protected just as other objects are protected. The creation of groups must be controlled, since becoming a member of a group can change the objects accessible to any member. In many systems, e.g., Multics, a user must be a member of at least one group. One detriment of the group mechanism is that changing the members of a group results in changes to an unknown set of ACLs for protected objects. Allocation of groups could be a Systems Administrator function only, or it could be distributed to a Project Administrator type function. Problems could result from allowing any user to create a group and then be "owner'' of that group. If users were prohibited from listing the members of groups they are not in because of covert channels and privacy, it would be difficult to determine if a group was the correct one to use. System or Project Administrator control is a preferred mechanism. Wild Cards A wild card mechanism allows a string replacement where the wild card is specified. For example, in the Multics system ```PAYROL rw'' gives read and write access to any user in the PAYROL group. ``Smith.* r'' gives Smith read access, no matter what group the user Smith belongs to. ``*.*'' gives any user access. The group and wild card mechanisms allow the ACL list to be kept to a reasonable size. The use of wild cards raises the possibility of conflicts if a user has multiple ACL entries for an object. In the above example, Smith has a possible conflict; as a member of any group he can read and as a member of the PAYROL group he can read and write. The system must make a decision as to which one of the ACL entries it will apply when granting Smith access to the object. Various systems have different rules for resolving conflicts. One approach might be to have the system enforce an ordering of the ACLs. Another approach might be to allow ordering of the ACLs by the users. In any case, the users must understand the rules in order to create effective ACL entries. A wild card mechanism adds more complexity, but does not affect the utility of a DAC mechanism.

Default ACLs There are many side issues in the implementation of access control lists. Default ACLs are usually necessary for the user friendliness of the DAC mechanism. At the very least, when an object is created by a user, the user should be placed on its ACL by default. Some of the other possible default mechanisms include a system-wide default, a user-associated default or if the file structure is a tree, a default associated with the directory. A system-wide default could be used as the default in cases where no other default had been specified. A system-wide default might give access only to the creating user. A user-associated default might work well on a system with a flat file structure. When a user is first entered on the system, his default ACL would have to be specified. For file structures that are trees, a default(s) associated with the directory

could be most efficient. If the user organizes the directory structure to represent project work or areas of interest, then the ACLs for all objects in a sub -tree would be similar. One default ACL in the directory would be for children that are files. For children that are directories either a separate sub-directory default ACL should be specified or the default ACLs should have to be stated explicitly by the user. Otherwise, unless care is taken, those with access to the root sections of the storage hierarchy could by automatic default get access to all of the storage hierarchy. The overriding principle of least privilege implies that the use of defaults should not inadvertently give away more access than the user intended. In other words, to err on the conservative side is preferred. In all implementations some user(s) must have permission to change the ACLs after they have been set by default, and the ability to change the defaults is very useful. Defaults can be implemented in two ways: they can be copied to the ACL or they can be pointed to by the ACL. If they are copied, then changes to the default will not affect the ACL; otherwise, changes in the default may cause changes in many ACLs. Named ACLs Another possible user friendly feature is "named" ACLs. One implementation of this feature uses a named ACL as a template. If a user often sets ACLs to the same list of Users, the setting user may want to create a named ACL as a template which, when used, copies that list into the ACL. When the named ACL is changed, there is no effect on the ACLs already in existence. This use of named ACLs has no particular detriments and is of limited usefulness. The other implementation of named ACLs places a pointer in the real ACL to the named ACL. Now when the named ACL gets changed, all of the real ACLs that use it also get changed. This is very convenient for the user, but when a named ACL is changed the user has no way of determining all of the protected objects affected by the change. The named ACLs also have to be protected in the same way as the real ACLs. Most of the features of named ACLs can be replaced by some group and default mechanisms. In summary, access control lists are the most desirable implementation of discretionary access control. ACLs conveniently lend themselves to specifying a list of named users who are allowed to access each object. Also, providing access to defined groups of users is easily done with ACL-based mechanisms.

PROTECTION BITS Protection bits are an incomplete attempt to represent the access control matrix by column. Implementation of protection bits includes systems such as UNIX which use protection bits associated with objects instead of a list of users who may access an object. In the UNIX case the protection bits indicate whether everyone, the object's group or only the owner has any of the access modes to the protected object. The user who created the object is the owner, and that can only be changed through superuser privileges. The owner is the only one (besides a superuser) who can change protection bits. The problem with protection bits is that they are an incomplete implementation of the access control matrix model. The system cannot conveniently allow or disallow access to a protected object on any single user basis. It has been suggested that groups be set up so that any needed combination of users can be specified. But, for

more than a few users, the combinatory of such a solution are unrealistic. Also, groups are controlled by the system administrator, and such a scheme would require full-time attention. PASSWORD DAC MECHANISMS Password protection of objects attempts to represent the access control matrix by row. If each user possessed his own password to each object, then the password is a ticket to the object, similar to a capability system (except, of course, with no dynamic domains). In most implementations of password protection, only one password per object or one password per object per access mode exists. Passwords on protected objects have been used in IBM's MVS and with other mechanisms in CDC's NOS to implement DAC. Many problems are associated with using a password protected DAC system. The use of passwords prevents the TCB from controlling distribution of access permissions. The sharing of passwords takes place outside the system. For a user to remember a password for each protected object is virtually impossible and if the passwords are stored in programs they are vulnerable. To restrict access to certain access modes requires a password for each combination of access modes, but in most systems that use passwords, access to a protected object is all or none. In such implementations, revoking a user's access requires revoking access from all other users with similar access and then distributing a new password to those who are to retain access. This becomes almost impossible when passwords are stored in programs. To be secure, passwords should be changed periodically, which is very difficult to do in such password protected DAC systems. In systems such as MVS the default access to a file is unrestricted access. A file is protected only when the password protection is initiated for that file. Thus a new file in MVS is not protected until the password protection mechanism is invoked. If passwords are used as in the CDC NOS system to supplement another DAC mechanism, they do have one positive aspect. If all objects are protected with different passwords, Trojan horses can be restricted to only the objects that are handed to them. The use of passwords for a complete DAC is strongly discouraged, because there is no way to determine who has access to an object, and because managing such a system properly is very difficult.

4. MANDATORY ACCESS CONTROL Mandatory access control (MAC) involves aspects that the user cannot control (or is not usually allowed to control). An example is that of a hardware address that cannot be changed by a user. Under MAC, objects are tagged with labels representing the sensitivity of the information contained within. MAC restricts access to objects based on their sensitivity. Subject needs formal clearance (authorization) to access objects. As an example, on Trusted Solaris, MAC relies on sensitivity labels attached to objects. The MAC policy compares a user's current sensitivity label to that of the object being accessed. The user is denied access unless certain MAC checks are passed. It's mandatory as the labeling of information happens automatically, and ordinary users cannot change labels. In contrast, DAC uses file permissions and optional access control lists (ACLs) to restrict information based on the user's ID

(uid) or his group ID (gid). It's discretionary as a file's owner can change its permissions at his discretion. 4. Windows 2000 Authentication Authentication is performed by the system to be sure the user is really who they claim to be. Authentication may be done at and for a local computer or at a global level for a domain using domain controllers across the network. Authentication uses X.509 standard and Kerberos. Process of Logging On 1. CTRL+ALT+DEL is pressed, name and password entered, and local or domain logon is indicated. 2. If the logon is local, the name and password are checked against the local database. If the logon is a domain logon, the name and password are encrypted into a key, and timestamp information is encrypted. This information is sent to the Windows 2000 domain controller with an authentication request. 3. The domain controller decrypts the information and checks for a valid timestamp. If the timestamp is valid, two Kerberos tickets are made and encrypted with the password. The tickets are sent back to the client computer. The tickets are: o User session key - Used to log on. o User ticket - Used to get other Kerberos tickets for accessing other domain resources. 4. The client decrypts the tickets and uses the session key to log on. Authentication when Accessing an Object 1. The user tries to access the network object. 2. The user ticket, user name, name of the object to access, and timestamp, are sent with a Kerberos ticket granting service request to the domain controller. 3. The domain controller decrypts the information, checks the timestamp, makes an encrypted session key (with user account and group information) and returns the key to the local client. 4. The client sends a request for the resource with the session key to the server that has the resource. 5. The receiving server decrypts the session key, and checks the information against its ACL for the object being requested. 5. UNIX Authentication In the UNIX operating system environment, files and directories are organized in a tree structure with specific access modes. The setting of these modes, through permission bits (as octal digits), is the basis of UNIX system security. Permission bits determine how users can access files and the type of access they are allowed. There are three user access modes for all UNIX system files and directories: the owner, the

group, and others. Access to read, write and execute within each of the user types is also controlled by permission bits.

Permission modes OWNER GROUP OTHERS

-----------------------------------------------------------------rwx : rwx : rwx

------------------------------------------------------------------r = read w = write x = execute -rw--w-r-x 1 bob csc532 70 Apr 23 20:10 file drwx------ 2 sam A1 2 May 01 12:01 directory
Each file (and directory) has associated access rights, which may be found by typing ls -l. Also, ls -lg gives additional information as to which group owns the file (beng95 in the following example):

-rwxrw-r-- 1 ee51ab beng95 2450 Sept29 11:52 file1

In the left-hand column is a 10 symbol string consisting of the symbols d, r, w, x, -, and, occasionally, s or S. If d is present, it will be at the left hand end of the string, and indicates a directory: otherwise - will be the starting symbol of the string. The 9 remaining symbols indicate the permissions, or access rights, and are taken as three groups of 3.

The left group of 3 gives the file permissions for the user that owns the file (or directory) (ee51ab in the above example); The middle group gives the permissions for the group of people to whom the file (or directory) belongs (eebeng95 in the above example); The rightmost group gives the permissions for all others.

The symbols r, w, etc., have slightly different meanings depending on whether they refer to a simple file or to a directory.

Access rights on files.

r (or -), indicates read permission (or otherwise), that is, the presence or absence of permission to read and copy the file w (or -), indicates write permission (or otherwise), that is, the permission (or otherwise) to change a file x (or -), indicates execution permission (or otherwise), that is, the permission to execute a file, where appropriate

Access rights on directories.

r allows users to list files in the directory; w means that users may delete files from the directory or move files into it; x means the right to access files in the directory. This implies that you may read files in the directory provided you have read permission on the individual files.

So, in order to read a file, you must have executed permission on the directory containing that file, and hence on any directory containing those directories as a subdirectory, and so on, up the tree.

Some examples
-rwxrwxrwx a file that everyone can read, write and execute (and delete). a file that only the owner can read and write - no-one else -rw------can read or write and no-one has execution rights (e.g. your mailbox file).

Chmod (changing a file mode)

Only the owner of a file can use chmod to change the permissions of a file. The options of chmod are as follows

Symbol u g o

Meaning user group other

a r w x + -

all read write (and delete) execute (and access directory) add permission take away permission

For example, to remove read write and execute permissions on the file biglist for the group and others, type

% chmod go-rwx biglist

This will leave the other permissions unaffected. To give read and write permissions on the file biglist to all,

% chmod a+rw biglist