Access.control is one of the cornerstones of system security. Access control mechanisms help in limiting access to system resources by any unauthor- ized access, including malicious code, copying of data, illegal actions, and exploitation of infrastructure dependencies. It is essential to determine how access control protection can be provided to each of the system’s resources. To do this, a good access control and access protection policy is needed. Ac-
cording to Panko (2004), such a policy has benefits, including:
• Focusing the organization’s attention on security issues resulting in better resource allocation toward system security
• Helping in configuring appropriate security for each system resource
based on role and importance of the resource within the system • Allowing system auditing and testing
Authentication.is the process of identifying and verifying the identity of a party who generated some data, like a request to use a system, and of the integrity of that data, making sure that request for using the system is genu- ine. The process will focus on traditional authentication techniques, like the use of passwords; newer methods, like the use of challenge-response; and some ad hoc ones.
Authorization is a process of checking and ascertaining by closely scrutinizing the credentials presented by the user of the system if that user has permission to use the requested system resources. The process, therefore, focuses on the
credentials presented and depends on specific rules, and the access control
regime presented. This makes authorization dependent on a good access control regime. Because of this, authorization should not be confused and used interchangeably used with access control.
Access.Control
There are several models of access control with varying degrees of effective- ness. These models include: access control matrix, capability tables, access
control lists, role-based access control, rule-based access control, restricted interfaces, and content-dependent access control. Many of these techniques are new in response to the rapid growth of the Internet. For a long time, ac- cess control was used with user- or group-based access control lists, normally based in operating systems. However, with Web-based network applications, this approach is no longer flexible enough, because it does not scale in the new environment. Thus, most Web-based systems employ newer models and technologies, such as role-based and rule-based access control, where access rights are based on specific user attributes, such as their role, rank, or
organizational unit. A successful access control regime, however, will prob-
ably employ a combination of several of these models.
Access.Rights
Access.rights are permissions granted to a user who requests access to use
the specified system resource or resources. Rights can be granted to an
individual user or groups of users. The permissions control user access to each system resource. So user A, who wants to access resource R, must have permission to access that resource, based on any one of the following modes: read, write, modify, update, append, and delete. Access control permissions are granted to a user or groups of users through validation of passwords and access mode permissions.
The access rights granted to a user refer to that user’s ability to access a system resource. There are four access rights: execute,.read,.append, and
write. The user is cautioned not to confuse access rights and access modes. The difference lies in the fact that you can perform any access right within each access mode. Figure 10.1 shows these differences. Along the column of the access matrix are rights and along the rows are modes.
Access rights can be set individually on each system resource for each in- dividual user and group. It is possible for a user to belong to a few groups and enjoy those groups’ rights. However, user access rights always take precedence over group access rights, regardless of where group rights are
execute append read write
observe X X
alter X X
applied. If there are inherited group access rights, they take precedence over user default access rights. A user has default rights when the user has no as- signed individual or group rights from root down to the folder in question. In the cascading of access rights application, user access rights that are closest to the resource being checked by the monitor take precedence over access rights assignments that are farther away.
The access rights model consists of four elements: subjects, objects, opera- tions, and a reference monitor. A subject is an entity that accesses a passive object based on an operation. A typical subject would be a user or a program process. An object is also an entity representing an element of the system.
Objects are usually files or system resources, like memory, printers, or disks.
An operation is a function performed by the subject or on behalf of the sub- ject on an object to produce an outcome. The relationship between a subject, object, and operation is shown in Figure 2.
An operation in Figure 2 would start with the subject, for example, a user,
initiating an access request for a specified system resource, usually a pas- sive object in the system, such as a Web resource. The request goes to the reference monitor that checks on the hierarchy of rules that specify certain restrictions. A set of such rules is called an access.control.list (ACL). When a request for access is made, before granting such a request, the monitor goes through the ACL rule base to check if there is any rule that would prevent it from granting such a request.
There are two access modes: observe and alter. In the observe mode, the sub- ject may only look at the content of the object; in the alter mode, the subject may change the content of the object. The observe mode is the typical read
in which a client process may request a server to read from a file.
Reference.Monitor
Subject Object
Access Request Access Request Granted