Analysis of Role-based Access Control (RBAC)

Published Date: 28 Feb 2018

ABSTRACT

Access control systems within an enterprise system are used to control the actions, functions, applications, and operations of legitimate users within an organization and to protect the integrity of the information stored within the system. Role-based access control (RBAC) is a relatively new access control system that maps to organizational-specific structures in a way that reduces administrative costs and improves security. Although role-based security models have existed for 20 years, their application has until recently been limited. We try to give a comparison between RBAC and traditional access control models and try to evaluate the different industries where these models can be utilized. We try to evaluate the NIST RBAC model as a standard for implementing RBAC and show the implementation by developing an application which uses RBAC for authentication and authorization for the computer system to be accessed. This also involves a discussion for different variations of the Role Based Access Control models according to NIST.

INTRODUCTION

Access control is generally concerned with determining what users and groups of users can perform which operations on certain resources [10][1][11]. The fundamental problem is that each system and application for which access control is enforced has a proprietary method for creating and managing users, groups, and a system specific meaning of operations and objects. For many organizations, the number of systems can be in the hundreds or even thousands, the number of users can range from hundreds to the hundreds of thousands, and the number of resources that must be protected can easily exceed a million.

Organization's large IT infrastructure is a mix of hugely complex and incompatible operating systems, applications and databases spread all over the world. The organizations these days have a huge number of employees which keep increasing or decreasing all the time according to the organization's need. It also has a working interaction with contractors, business partners, and customers, all of whom require access to various parts of the infrastructure. Most of the companies rely on manual or semi-automated administration of users, controlling their access to privileges for various resources on a particular system. This will inevitably become very complex and completely unmanageable if the organization is huge and the number of users of the system is in thousands or more. Often, different systems will have their own set of access requirements with different sets of administrators who will have overlapping skill-sets, leading to poor use of resources. This creates an enormous administrative overhead e.g. If there is a single administrator who needs to update even 25% of thousands of users everyday, it will almost be impossible for the system admin to do so. Furthermore, if multiple administrators are acquired for this job it could cause conflicts so the system becomes almost impossible to handle and maintain. Also, it would cost much more than if you were to have a single administrator.

As the complexity of the organization's IT infrastructure increases, the demand for access control administration across the enterprise outgrows the capacity of manual administration across the distributed systems. Increased administrative complexity can also result in increased errors that, in turn, can lead to increased security risks. It is best suited to use the access control models to restrict unauthorized access and avoid any security risks. Access Control Models have long been used in enterprise systems and ERP's so that the system is made secure and reliable, restricting access to sensitive and confidential information resources from unauthorised users [10]. Different access control models are suited for different business applications and industries depending upon the scale and complexity of the system being developed. This report will try to analyze the different types of access control models as discussed above, that may be suitable for a variety of businesses and industry applications, giving their features, benefits and classification.

This document will be covering many issues related to access control and various access control models. The critical analysis of each of the traditional access control model will be provided as well as the comparisons with each other identifying their advantages and drawbacks. The industry specific implementation of each of the model will also be discussed i.e. which model is suited for which kind of industry and what models should be selected depending on the scale of the system. Then the more recent access control model which is being widely utilized nowadays will be discussed in more detail and its different versions will be evaluated. Also role-based access control will be discussed in different environments i.e. in a centralized application environment and also in a distributed application environment. In the end, there will be an implementation of the appropriate access control model for a particular industry application called BOS (Back Office System) that is a travel agency. This application will support the day to day business operations of the organization. The model used for this application will be Role-Based access control as the structure and requirements of the business will be supported using this RBAC. It does not require the ACLs of DAC and it does not need the high security of MAC because the access privileges can be interchangeable between the users of the system.

BACKGROUND

Access Control Models have long been used in enterprise systems and ERP's so that the system is made secure and reliable, restricting access to sensitive and confidential information resources from unauthorised users. The basic need of access control is to protect the system and its contents from intentional and unintentional damage, theft and unauthorised disclosure. The access control models that have been used in the recent decades are traditional access control models which are Access Control Lists (ACL's), Discretionary Access Control (DAC) and Mandatory Access Control. Role Based Access Control (RBAC) is a more recent access control model which provides an alternative for the traditional access control models.

The most appropriate way to restrict access of resources from unauthorized users of the system is to use one of the traditional access control models as a means of implementing secure and reliable access for that system. There are many access control models present in this age of time which cater to different needs and provide different type of security depending on the nature, scale and type of the application as well as the industry for which the application is being implemented for.

Traditional access control models base access control on the discretion of the owner or administrator of the data. Under all traditional models, an end-user's identity determines which access permissions are needed. This section gives a brief introduction to the predominant traditional access control models as well as some of the more recent models that have been utilized more recently. We discuss these models in more detail in the later sections:

• Access control lists (ACLs).
• Discretionary Access Control (DAC).
• Mandatory Access Control (MAC).
• Role-Based Access Control (RBAC).

Access Control Lists

ACL's is one of the most common access control model being used for securing operating systems, applications, computer resources and networks. When ACL's is selected as a model for implementing access control, each resource that needs to be secured has a list of users associated with them who are authorized to access the resource and even modify and make changes in it if they are allowed to. ACL's as a model provides ease of access for the security administrator to see which users have access to which resource within the application or system. Also, modifying access to a piece of information is relatively simple; a security administrator can simply modify a user from the ACL list that is a user can be created, edited or even deleted easily.

There is a corresponding ACL present for every data or application, but it is not necessary to have a corresponding list that gives the network administrator information on all of the pieces of information to which a particular user has access. The only way for the security administrator to find out about any potential security violations on a particular data has to be checked by accessing each of the data individually. If the security administrator wants to revoke all the access privileges for a certain user, the administrator has to examine each list and then have to remove the user from each of the lists one by one.

Responsibilities for a user in an organisation may change, in this kind of scenario this model becomes more complicated and hard to manage. Instead of removing the user from every ACL, the network administrator has to determine which permission needs to be removed, modified or added somewhere according to the new position of the user in the organisation. In some situations the user can be grouped together in the list making it easier to change the ACL by just modifying the group information rather than each of the users individually. In some other cases elaborate rules can be applied to ACLs to restrict access to particular resource.

Discretionary Access Control Using Access Control Lists

Discretionary Access Control

The user who owns the data is the one who control access to that data in the discretionary access control model. ACL is a model which is derived from 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 [1].

Discretionary Access Control is used to stop the user from accessing the 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 which are performed on an object by a user, the operations include read, write and execute. Usually an object belongs to a user or a user is the owner of that object, this means that only the owner of the object has the authority to distribute and revoke access to that object. The owner of the object may give and retain access to the objects they control based on the rules of the DAC. The identity of users and objects is the fundamental basis for controlling access in a system within this model i.e. DAC specifies which users have access to which part of the information.

Mandatory Access Control

Mandatory Access Control is different from other access control models in a way that the security it provides is based on hierarchy and assigns each subject and object a specific security level (e.g., classified, secret, top secret etc.). The rules that govern the access to a particular for this model are:

No read up.

No write down or (own level write only).

Read down access gives users the ability to access any piece of information that is at or below their own security level. If a user has a secret security level, they are able to access secret and classified material but not top secret material. Write up access states that a subject's clearance must be dominated by the security level of the data or information generated. For example, someone with a secret clearance can only write things that are secret or top secret. With these two access control principles, information can only flow across security levels or up security levels [1].

Mandatory Access Control

Role Based Access Control

In traditional access control models the approach for granting access to resources within a particular system or an application is to specify permission for each of the user within an organization. If the user is allowed to have access to multiple resources or information within a system, the user must be assigned permissions for each of the resource. This approach is tricky and not the most reliable way of implementing access control. When users join, leave or change responsibilities within an organization, each of the users who changes status within the organization that user's access privileges information must be updated for each of the permissions. Achieving the above requires a lot of resources, time and also is prone to errors as an organization can have hundreds of thousands of employees and updating each of the users information one by one is not an efficient way. RBAC get rids of this problem because it takes advantage of the user's role as the key to access rather than the user's identification.

The basis for role-based model is the user-role and permission-role relationships. Each user in a role-based environment may be assigned to multiple roles, and each role may have multiple users as well. The roles that are assigned to a user depend on their job and responsibilities, and each role is assigned permissions according to role's access privileges in the organization. Permissions determine the data and applications that may be accessed by which are also assigned to a role and that role is assigned to a user or multiple users. User's role can be in many forms e.g. jobs like (bank teller, bank manager), geographic locations (London, Newcastle) or individuals (shift supervisor, managers). The advantage of using this model is that users keep changing with in the organization whereas on the other hand roles or job responsibilities for a particular role remain the same. Therefore rather than implementing the security on the user's manually, roles are created which are assigned to users and any addition in a job specification is changed in the role description which in turn changes the all the user with that role.

RBAC is a technology that offers an alternative to traditional discretionary access control (DAC) and mandatory access control (MAC) policies. RBAC allows companies to specify and enforce security policies that map naturally to the organization's structure. That is, the natural method for assigning access to information in a company is based on the individual's need for the information, which is a function of his job, or role, within the organization. RBAC allows a security administrator to use the natural structure of the organization to implement and enforce security policy. This model decreases the cost of network administration while improving the enforcement of network security policies.

RBAC is designed to centrally manage privileges by providing layers of abstractions that are mapped one-to-many to real users and real operations and real resources. Managing permissions in terms of the abstractions reduces complexity and provides visualization and a context for implementing complex access control policies. Abstractions can be centrally managed resulting in real permissions on real systems.

Role-Based Access Control

Discretionary Access Control (DAC)

In a computer system, access controls restrict subjects (users and/or processes) to performing only those operations on objects (e.g., files) for which they are authorized. For each such operation, the access controls either allow or disallow that operation to be performed [3]. DAC model works on the basis that only the owner of a resource has the capability to authorize other users to have access to the same resource. This means that the users who do not have access to a particular resource and wants access to it, only the owner of that resource has the right to give access to them.

In Discretionary Access Controls (DACs), each object has an owner who exercises primary control over the object. ACL is one of the mechanisms which can be used to implement DAC and is one of the most widely used implementation for DAC. The access of information in DAC is based on the user's identity and the rules that specify the user's ability to have access to a certain protected resource or information. On the other hand ACLs are lists that specify user's access privileges for the protected objects. DAC consists of set of rules which specify a user's ability to access restricted resource or information. When a user wants access to a particular resource or information, the server searches the rule which specifies the user's ability to have access to the particular resource which it wants access to. If the rule is found and there is a match for the user to have access than the user is allowed access to the resource, if there no match then the access for the resource to the user is denied. For example, there may be a rule which states that users from a certain group is not allowed to have access to a certain piece of information.

Discretionary access control (DAC model) works on the discretion of the identity of the user. In DAC access to any object (files, directories, devices, information etc.) is only allowed if the owner of that object is willing to give access. Therefore, the basis of this model is creator-controlled sharing of information and identity of the owner plays an important role in the working of this method. The owners of objects can specify at their own discretion in what ways they want to share their objects to other users i.e. which other users can have what level of access to the objects they own. This can be implemented in a fairly simple way by using access control matrix which contains the names of users on the rows and the names of objects on the columns giving information of which users has access to which corresponding object. 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 [1].

ACCESS CONTROL MATRIX

The access control matrix is a combination of rows and columns with cells representing the permissions. In the matrix, the rows represent user/subjects and columns represent resources / objects. 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" [1]. The entries in the matrix describe what type of access each user has to each object. This representation of rows and columns is dependent on the model or mechanism being selected for Discretionary Access Control. The table below exhibits a good example of an Access Control Matrix.

ACCESS CONTROL MATRIX

The access control matrix such as the example above is a graphical view of a set of users and their access rights on particular set of protected objects. The access types mentioned in the table above are:

r denotes read access.

w denotes write access.

c denotes control permission access.

cp control passing ability.

CHARACTERISTICS OF DAC MECHANISMS

The complete implementation of DAC is based on the information which is stored in the form of an access control matrix. DACs are oldest and most widely used class of access controls, the access controls for both Windows and UNIX are DAC. The Unix DAC, for example, has the well known three primitive permissions read, write, and execute. When the initial implementation of DAC started, the five basic mechanisms that were used initially to represent information were:

• Capabilities
• Profiles
• Access Control Lists (ACLs)
• Protection Bits
• Passwords

The first two mechanisms that are capabilities and profiles represent the access control matrix information by row, connecting the accessible objects to the user. Whereas ACLs and protection bits represent the access control information by columns, connecting a list of users to an object. In the above five mechanism we will be mostly concentrating on the ACL model which is the most widely used model out of all of the mechanism present for DAC and also in this section a brief description of the other mechanisms will be provided [1].

Capabilities

In a capability-based mechanism for DAC, access to objects which have restriction on them being accessed such as files is granted if the user who wants access to it has the capability for that 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 [1]. The basic properties of capabilities are:

The capability of one user can be passed onto another user.

The user who possesses capability may not alter or fabricate capabilities without the interference of TCB (Trusted Computing Base).

If a capability mechanism is used to implement DAC than the implementation should possess the facility to transfer capability from one user to other users. This ability of transferring capability from one user to another cannot be controlled and therefore capabilities has to be stored, determining all the users access for particular objects almost becomes impossible. Because of this reason implementing DAC using the capability mechanism becomes very difficult including the feature of revocation.

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.)[1].

Profiles

This is another mechanism which can be used to implement DAC and have been used in some forms for several systems. When using Profiles [1] to implement DAC, a list of protected objects is used to associate each user to the particular object. The object names are inconsistent and they don't agree on being grouped together, also their size and number are difficult to reduce. If a user has access to a large number of protected objects, the profile can also become very large and it is very complex to manage such a profile. In profile mechanism all protected object names should be unique to but in reality multiple objects can have multiple names, because of this reason full pathnames should be used to identify the objects uniquely.

One major drawback of this method is that when creating, modifying or deleting access to protected objects requires multiple operations because multiple users might have access to the same object therefore those user's profile must be updated. Revoking access to an object in time for a user is very difficult unless the user's profile is automatically checked each time that object is accessed. Also if some object is deleted, it will require some method to check whether that object exists in each of the user's profile or not, which is also an extra overhead.

In general, with these two mechanisms i.e. Capabilities and Profiles it is very difficult to check whether which users have access to a particular protected object. This is a very important problem that needs to be addressed in secure system and there exists more feasible and more efficient mechanisms, the above two mentioned mechanisms are not the recommended implementations for DAC.

ACCESS CONTROL LISTS (ACLs)

Another approach to implement the DAC model for access control using the access matrix is by means of the access control lists (ACLs). When using ACLs, each object is related with an ACL, these ACL entries indicate the authorities a subject possesses which can be executed on that object. In the ACL mechanism the access control matrix is represented by columns.

By looking at an object's ACL it is easy to determine which modes of access subjects are currently authorized for that object. In other words, ACLs provide for convenient access review with respect to an object. It is also easy to revoke all accesses to an object by replacing the existing ACL with an empty one. On the other hand determining all the accesses that a subject has is difficult in an ACL-based system. It is necessary to examine the ACL of every object in the system to do access review with respect to a subject. Similarly if all accesses of a subject need to be revoked all ACLs must be visited one by one. (In practice revocation of all accesses of a subject is often done by deleting the user account corresponding to that subject. This is acceptable if a user is leaving an organization. However, if a user is reassigned within the organization it would be more convenient to retain the account and change its privileges to reflect the changed assignment of the user.)

Several popular operating systems, such as UNIX and VMS, implement an abbreviated form of ACLs in which a small number, often only one or two, group names can occur in the ACL. Individual subject names are not allowed. With t

his approach the ACL has a small fixed size so it can be stored using a few bits associated with the file. At the other extreme there are a number of access control packages that allow complicated rules in ACLs to limit when an how the access can be invoked. These rules can be applied to individual users or to all users who match a pattern defined in terms of user names or other user attributes.

Access control is required to achieve secrecy integrity, or availability objectives. ACLs have been a popular approach for implementing the access matrix model in computer operating systems. Some systems approximate ACLs by limiting the granularity of the ACL entries to one or two user groups. Other systems allow considerable sophistication. ACLs have disadvantages for access review and revocation on a per-subject basis, but on a per-object basis they are very good. More flexible representation such as authorization tables provide for superior management of access rights, but are usually available only in database management systems. In a distributed system a combination of capabilities for coarse-grained control of access to servers, with ACLs or authorization tables for finer-grained controls within servers, is an attractive combination [10].

ACL MECHANISM WORKING

ACLs allow any particular user to be allowed or disallowed access to a particular protected object. They implement the access control matrix by 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 ``user-id.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 [13]. 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 [14], 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. An exclusion capability, which allows a group to be specified with certain members to be excluded, is also useful and is required at class B3 and above.

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.

7.4 PROTECTION BITS

Protection Bits is one of the column-based mechanisms to implement access control matrix. This method is not appropriate as its implementation is not complete for the requirements of access control matrix. One such system which uses protection bits in its implementation is UNIX [15]. Instead of using list of users who may access an object, UNIX uses protection bits associated with objects. The implementation of protection bits in UNIX gives information about the access modes to the protected object which may be applied to either the object's group or the owner of the object. The user who created the object is the owner, and the ownership of a certain object can only be changed through the superuser privileges. The protection bits can only be changed by the owner with the exception of a superuser.

The trouble with Protection Bits is that there implementation for access control matrix model is not complete. When a system is developed based on the mechanism of Protection Bits than it is not convenient for that system to easily grant or revoke access to a protected object on any single user basis. For this reason it is recommended that a group of user be set up so that instead of specifying a single user a combination of users can be specified. If the number of users is less that is very few users are comprised of a group than such a solution is not appropriate. Also for the administration of groups a full time administrator is required which will be able to provide full time administration for the management of the group.

7.5 PASSWORD DAC MECHANISMS

Password protection of objects for DAC is implemented as a row-based access control matrix. In this mechanism each user possess a password for each object it wants access to, this password becomes a ticket to that object. This technique is very similar to capability system except that there are no dynamic domains being used in password protection. Usually one password per object or one password per object per access mode exists. IBM's MVS [6] (Multiple Virtual Storage) and CDC's NOS [7] (Network Operating System) have utilized Password mechanism to implement security for protected objects.

When using a password protected DAC system there seems to be a lot of problems with it. The usage of password stops the TCB (Trusted Computing Base) from domineering allocation of access permissions. There is no sharing of password allowed within the system, if sharing of password does happen than it has to happen outside the system. It is almost impossible for the user to remember the password for each of the protected objects and if the passwords are stored in the program itself than the system becomes susceptible to security threats or information leakage. To apply restriction to a combination of certain access modes, a password is required for those access modes, but in most system that uses password mechanism, access to a protected object is all or none. In the above mentioned systems, revoking an access privilege from a user requires revoking access from all the users who have the same access privileges and then assigning new passwords to those who are to retain access. This becomes impossible when passwords are stored in programs. To ensure security, passwords must be changed periodically, which is very difficult to achieve in password protected implementation of DAC systems. In MVS the default access to a file is unrestricted access i.e. when a file is created in the MVS environment it is accessible without any restriction. A file is only restricted for access when password protection is initiated for that file. Thus a new file is not protected until the password protection mechanism is activated [1].

If passwords are used as they are used in CDC NOS system [7] it will give an additional advantage to the mechanism which is used in IBM's MVS operating system. This advantage is that if each object is protected with a different password than Trojan horse threat can be limited to the extent i.e. each password that is presented to the Trojan horse is vulnerable other than that all objects should be secure.

Generally, use of passwords for a complete implementation is always discouraged because there is no way to determine which user has access to which object and also because managing such a system is very difficult and complex.

Limitation of DAC:

The discretionary access control mechanism in the operating systems was not designed to take buggy software in mind. Therefore the problem with Discretionary Access Control is that it cannot protect against Trojan horses, Malware, software bugs and malicious users. DAC allows information from an object which can be read to any other object which can be written by a subject i.e. DAC is unable to provide multi-level security. Suppose users of a system are trusted not to do this deliberately. It is still possible for Trojan Horses to copy information from one object to another.

Global Policy

An individual user can set an access control mechanism to allow or deny access to an object when using DAC. So the access to any object relies on the owner of the object rather than the policy of the DAC. Users can implement their own access control policies on the data they own, regardless of whether those policies are in conflict with the global policies. Therefore, it is hard to enforce the consistency of the global policy for each of the protected data within the system.

Information Flow

Information contained in one object can be copied to another object, if the owner of the original object has mentioned in the access control policy that the access to information to the particular object is restricted than the copy which has been made must also satisfy the same. But this is not the case the copy may be accessible and hence therefore conflicts with the original access policy of the object. This has been a major flaw because of which military application does not use this mechanism for implementing security rather they prefer Mandatory Access Control.

Malicious Software
DAC policies can be easily changed by owner, so a malicious program (e.g., a downloaded untrustworthy program) running by the owner can change DAC policies on behalf of the owner. This basic principle of discretionary access control contains a fundamental flaw that makes it vulnerable to Trojan horses [8]. A Trojan horse does what a user expects it to do, but in addition exploits the user's legitimate privileges to cause a security breach. On most systems, any program which runs on behalf of a user inherits the DAC access rights of that user [5]. An example of the workings of a Trojan horse will illustrate how most DAC mechanisms are vulnerable. This example should exhibit to the reader that discretionary access control is only useful to contain the ``honest'' user in accessing other user's files and preventing accidental disclosure or destruction of information. This issue can only be resolved by other means that is the malicious user cannot be stopped by using DAC mechanism and therefore another model needs to be used to ensure security with in the system, such as mandatory access control. Reference [6] contains such an example, which is similar to the following:

AN EXAMPLE OF A TROJAN HORSE [1]

Consider a system where an access control list mechanism as described in the earlier sections 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 DRAKE's address space called DRAKESFILE. DRAKESFILE has an ACL associated with it that allows processes executing on DOE's behalf to write to it, while allowing DRAKE's 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.

The example above should give a good idea about the danger of Trojan horse attacks and failure to protect against such attacks in most of the DAC mechanisms. Therefore even a detailed DAC mechanism may provide deceptive security to subject/users who do not know the fact that the mechanism used to implement DAC is vulnerable to Trojan horse attacks.

By implementing multiple domains or even a few dynamic domains for each process in the system, Trojan horse threats can be lowered to a certain degree. All of the user's objects are available to the user's process which is running on its behalf. For each of the process if creation of domains can be made dynamic with only the necessary objects available in that domain then the Trojan horse will be limited to accessing only those objects which are available in that domain. Least privilege principle can be useful in the above mentioned scenario.

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.

CUMBERSOME ADMINISTRATION

DAC implementation makes the management of the user complex e.g. a user leaving the company or user being promoted to another function in the company are the scenarios in which the information has to updated manually and if the number of employees in a company is huge than this kind of administration can be hectic and time consuming. Also because of the nature of the manual administration it can be prone to errors and mistakes which makes the system unreliable.

IMPLEMENTATION OF DAC

Discretionary Access Control has been used by most of the mainstream operating systems .For instance, DAC is implemented on multi-user operating system such as UNIX and Windows NT. Below is a brief description of the implementation of both the major operating systems that have used DAC to implement their security.

Unix/POSIX Access Control Mechanism [9]

Traditional UNIX uses a restricted form of access control list on files. Peripheral devices are represented by special files. Every user is identified by an integer number (user ID).

Every user also belongs to at least one group", each of which is identified by an integer number (group ID). Processes started by a user inherit the user and group ID. Each file carries both an owner's user ID and a single group ID. Each file carries nine permission bits. The first three specify whether read", write", and execute" access is granted if the process user ID matches the file owner ID. Otherwise, if one of the group IDs of the process matches the file group ID, the second bit triplet determines access. If this is also not the case, the final three bits are used.

In the case of directories, the read" bits decide whether the names of the files in the directory can be listed and the execute" bits decide whether search" access is granted, that is whether any of the attributes and contents of the files in the directory can be accessed via the directory. The name of a file in a directory that grants execute/search access, but does not grant read access, can be used like a password, because the file can only be accessed by users who know its name. Write access to a directory is sufficient to remove any file and empty subdirectory in it, independent of the access permissions for what is removed.

Berkeley Unix added a tenth access control bit: the sticky bit". If it is set for a directory, then only the owner of a file in it can move or remove it, even if others have write access to the directory.

Many UNIX programs require installation with set-user-ID root, because the capabilities to access many important system functions cannot be granted individually. Only root can perform actions such as:

Changing system databases (users, groups, routing tables, etc.)

opening standard network port numbers < 1024

interacting directly with peripheral hardware

overriding scheduling and memory management mechanisms

Applications that need a single of these capabilities have to be granted all of them. If there is security vulnerability in any of these programs, malicious users can often exploit them to gain full superuser privileges as a result.

Windows NT/2000/XP Access Control [9]

Microsoft's NT is an example for considerably more complex access control architecture.

All accesses are controlled by a Security Reference Monitor. Access control is applied to many different object types (files, directories, registry keys, printers, processes, user accounts, etc.). Each object type has its own list of permissions. Files and directories on an NTFS formatted hard disk; for instance, distinguish permissions for the following access operations:

Traverse Folder/Execute File, List Folder/Read Data, Read Attributes,

Read Extended Attributes, Create Files/Write Data, Create Folders/

Append Data, Write Attributes, Write Extended Attributes, Delete

Subfolders and Files, Delete, Read Permissions, Change Permissions,

Take Ownership

Note how the permissions for files and directories have been arranged for POSIX compatibility.

As this long list of permissions is too confusing in practice, a list of common permission options (subsets of the above) has been defined:

Read, Read & Execute, Write, Modify, Full Control

Every user or group is identified by a security identification number (SID), the NT equivalent of the UNIX user ID. Every object carries a security descriptor (the NT equivalent of the access control information in a UNIX i-node) with

SID of the object's owner

SID of the object's group (only for POSIX compatibility)

Access Control List, a list of Access Control Entries (ACEs)

Each ACE carries a type (AccessDenied, AccessAllowed, SystemAudit), a SID (representing a user or group), an access permission mask, and an inheritance attribute (specifies whether the ACE refers to the object, its children, or both).

Requesting processes provide a desired access mask. With no ACL present, any requested access is granted. With an empty ACL, no access is granted. All ACEs with matching SID are checked in sequence, until either all requested types of access have been granted by AccessAllowed entries or one has been denied in an AccessDenied entry.

GUI interfaces with allow/deny buttons usually place all AccessDenied ACEs before all AccessAllowed ACEs in the ACL, thereby giving them priority.

SystemAudit ACEs can be added to an object's security descriptor to specify which access requests (granted or denied) are audited. Users can also have capabilities that are not tied to specific objects (e.g., bypass traverse checking).

Default installations of Windows NT use no access control lists for application software, and every user and any application can modify most programs and operating system components (virus risk).

Windows NT has no support for giving elevated privileges to application programs. There is no equivalent to the UNIX set-user-ID bit.

A service is an NT program that normally runs continuously from when the machine is booted to its shutdown. A service runs independent of any user and has its own SID.

Client programs started by a user can contact a service via a communication pipe, and the service can not only receive commands and data via this pipe, but can also use it to acquire the client's access permissions temporarily.

Detailed practical NT security administration guidelines: http://nsa1.www.conxion.com/

SUMMARY OF DAC MECHANISMS

Access control lists are the most appropriate and feasible way of implementing DAC and it satisfies the entire requirement for DAC if implemented properly. Protection bits lack the ability to conveniently control access to each object to the granularity of a single user [1]. Row-based methods, such as capabilities and profiles, may occur with problems such as revocation of access and group access to objects. Passwords should not be used as a primary mechanism to implement DAC. It can provide supplementary functionality and help in avoiding Trojan horse vulnerability when implementing DAC. Its implementation alone as DAC is not recommended.

The preferred DAC mechanism within the current state-of-the art is the access control list. The deletion of the subjects and objects is a potential problem for any DAC mechanism, including ACLs. Regardless of whether a subject or object is deleted the mechanism should handle the deletion efficiently, making sure that any dangling references do not grant unintended access after the deletion. An asset of ACLs is their design, which represents the access control matrix by column. An object's ACLs are automatically purged when the object is deleted. Unlike row-based mechanisms, ACLs do not require searching the profiles of all the subjects to determine who has access to he deleted object. However, when subjects are removed from the ADP system, ACLs pose the same problem; all system objects must be searched to purge that subject from all ACLs. Since objects are much more volatile than subjects, ACLs are more efficient than profiles [1].

Another improved version of ACLs which is known as Rule-based DAC tries to improve some of the security deficiencies in ACLs but it is still prone to human errors and therefore may still cause security breaches. When a user gets access to a resource in DAC environment then there are no restrictions on data access for that particular user. Once users can access data, they can change or pass that information onto any other user without the security administrator's knowledge [10].

Discretionary Access Control cannot deter hostile attempts to access sensitive information. DAC mechanisms can be designed to eliminate casual browsing through the storage system, to prevent accidental disclosure, modification, and destruction of data, and to provide for the sharing of data between users. A mandatory security policy must also be implemented to provide adequate protection if users are not allowed to share all data on the system. An effective audit trail mechanism is also necessary in order to detect hostile attacks on the DAC mechanism [1].

MANDATORY ACCESS CONTROL (MAC)

In DAC model access to a particular resource is based on the discretion of the owner of that resource. DAC has had a few problems and one of the problems was when a user gets access to a resource that user has full access privileges to exercise over that object or resource i.e. there is no multi-level security present in DAC. Also the inconsistency of the access control policies in DAC made the system less trustworthy as the priority to allow users to access an object was given to the owners of the objects rather than the system administrator or system policies. As DAC did not fulfil the requirement for very secure and multilevel security for military and intelligence organizations, there was a need of another access control model which could satisfy the needs of such an application which possesses very sensitive and critical information which may be highly confidential.

Mandatory access control is another model which can be used to implement access control. It is much more secure and reliable than DAC model but in some cases it is difficult to implement and very complicated for the system administrator to manage it as the policies can be very strict and requires a lot of management from not only one but sometimes multiple system administrator. This is because of the strictness of the model and that it provides high level security for the system which is being implemented.

In Mandatory Access Control model the access to objects is based on a system-wide policy and is completed controlled and monitored by that policy, for example to prevent certain flows of information. Using the system-wide policy MAC can deny users full control over the access to resources that they create. The system security policy (as set by the administrator) entirely determines the access rights granted. In some forms, the system maintains security labels for both objects (resources, information) and subjects (processes, users), based on which access is granted or denied. Labels can change as the result of an access. Security policies are enforced without the cooperation of users or application programs [9].

When using MAC as the access control model, restrictions to allowed information flows are not decided at the user's discretion (as with UNIX chmod which uses DACs implementation), but instead enforced by system policies. A system-wide policy judges who is allowed to have access; individual user are not allowed to make modifications in that access. Mandatory access control mechanisms particularly aims towards avoiding system-wide policy violations by untrustworthy application software, which have at least the same access privileges as the invoking user. These policy based restrictions eliminate the possibility of Trojan horse problem that was present in Discretionary Access Control models. The access of resources/objects relies on the system when MAC is used to implement access control within a system because granting or invoking access is controlled by the system policies rather than the owner of the resource itself.

A real life example of the MAC model can be as follows:

The law states that a court can have access to driving records without the permission of the owner of those records. In this case law can be seen as the system policy which states that a court can have access to driving records of a person without that person's permission. The person whose driving records are being checked can be taken as the owner of the resource and the resource or object in this scenario are the driving records itself. The court can be seen as the subject who wants access to the driving records.

Traditional MAC mechanism have been tightly coupled to a very few models and there use was limited to special purpose military applications only. Usable MAC systems are not readily available i.e. implementation Mandatory Access Control security is only achieved through proper policy configuration, which is extremely difficult to do even for the security experts. Recently, systems supporting flexible security models started to appear and operating systems like SELinux (Security Enhanced Linux), Trusted Solaris, TrustedBSD etc. have used MAC model to enhance the security of these operating systems. Initial implementation of MAC used Bell-LaPadula Security Policy Model, which was used to implement time-sharing mainframe systems of U.S. Airforce when concerns were shown over the systems security.

MAC MECHANISMS

Security Policy Model

A security policy model is a succinct statement of the protection properties that a system, or generic type of system, must have.

Multi-Level Security (MLS)

The capability of a computer system to carry information with different level of sensitivities (i.e. classified information at different security levels), permit simultaneous access by users with different security clearances and needs-to-know, and prevent users from obtaining access to information for which they lack authorization. People and information are classified into different levels of trust and sensitivity. These levels represent the well-known security classifications: Unclassified, Confidential, Secret, Top Secret. Typically MAC uses this mechanism to be used in the implementation of different systems. The primary goal of this mechanism is to achieve confidentiality among users of the system and restricting unauthorised access of sensitive and critical information. The security classifications levels mentioned above can be represented in the figure mentioned below:

Clearance Level

Clearance Level indicates the level of trust given to a person with a security clearance, or a computer that processes classified information, or an area that has been physically secured for storing classified information. The level indicates the highest level of classified information to be stored or handled by the person, device, or location.

Classification Level

Classification level indicates the level of sensitivity associated with some information, like that in a document or a computer file. The level is supposed to indicate the degree of damage the country could suffer if the information is disclosed to an enemy.

[A Multi-Purpose Implementation of Mandatory Access

Control in Relational Database Management Systems ]

WORKING OF MAC

Mandatory Access Control (MAC) is a means of restricting access to objects based on the sensitivity (as represented by a label) of the information contained in the objects and the formal authorization (i.e., clearance) of subjects to access information of such sensitivity [12]. A well-known implementation of MAC is Multilevel Security (MLS), which, traditionally, has been available mainly on computer and software systems deployed at highly sensitive government organizations such as the intelligence community or the U.S. Department of Defence. The Basic model of MLS was first introduced by Bell and LaPadula [13].

The Bell-LaPadula Security Policy Model

This model is the most widely recognized MLS model and has been in use for the implementation of multi-level security in different application areas. Bell-LaPadula model deals with the confidentiality of the system being implemented. It was proposed by David Bell and Len LaPadula in 1973, it was built to remove the security deficiencies which were mentioned by the U.S. Airforce in the time-sharing mainframe systems. Bell-LaPadula [15] is a formal policy model for mandatory access control in a military multilevel security environment. In this model the system policy automatically prevents the flow of information from high-level objects t