Authorization and Access Control
4.2 Discretionary Access Control Policies
A discretionary access control policy is based on the definition of a set of rules, called authorizations, explicitly stating which user can perform which action on which resource. These rules can be represented as triples of the form (s, o, a) stating that user s can execute action a on object o. When a user makes an access request, the policy is enforced on the basis of the identity of the requester and on the rules involving herself. Different discretionary access control policies and models have been proposed in the literature. The first proposal is theaccess matrixmodel [3, 4, 5]. LetS,O,Abe a set of subjects that can interact with the access control system, a set of objects belonging to the system that need to be protected, and a set of actions that can be executed over the objects, respectively. In the access matrix model, the state of the system, that is, the authorizations defined at a given time in the system, is represented as a matrix A with a row for each subject and a column for each object in the system. Each entryA[s, o] contains the list of actions that subjectsis allowed to execute over objecto. For instance, suppose that there are four users, namely Alice, Bob, Carol, and David, five objects, namely Invoice1, Invoice2, Order1, Order2and Program1, and the set of actions contains read, write and execute. Figure 4.1 illustrates an example of an access matrix. The state of the system can be changed by invoking commands that execute primitive operations. These primitive operations allow one to create and delete subjects and objects in the system and to modify the set of actions that a subject can execute over an object.
Although the access matrix model can be easily implemented through a two-dimensional array, this solution is expensive because in general the matrix will be sparse and therefore many cells will be empty. To avoid such a waste of memory, the access matrix can actually be implemented through the following three mechanisms.
• Authorization table.The non-empty entries ofAare stored in a table with three attributes, namelysubject, action, and object. This solution is
42 S. De Capitani di Vimercati, S. Foresti, P. Samarati
Table 4.1. Authorization table corresponding to the access matrix in Fig. 4.1 User Action Object
Ann read Invoice1 Ann write Invoice1
Ann read Order1
Ann execute Program1 Bob read Invoice2 Bob write Invoice2
Bob read Order2
Bob execute Program1 Carol read Order1 Carol write Order1 Carol read Order2 Carol write Order2 David read Invoice1 David read Invoice2 David write Invoice2 David read Program1 David execute Program1
adopted in the database context where authorizations are stored in the catalog.
• Access control list (ACL). The access matrix is stored by column, that is, each object is associated with a list of subjects together with a set of actions they can perform on the object.
• Capability. The access matrix is stored by row, that is, each subject is associated with a list of objects together with a set of actions the subject can perform on the objects.
For instance, with respect to the access matrix in Fig. 4.1, the correspond-ing authorization table is illustrated in Table 4.1, while the access control lists and capabilities are represented in Figs. 4.2 and 4.3, respectively.
Access control lists and capabilities allow the efficient management of au-thorizations with respect to specific operations at the expense of others. More precisely, access control lists allow direct access to authorizations on the basis of the object they refer to; it is expensive to retrieve all the authorizations of a subject because this operation requires the examination of the ACLs for all the objects. Analogously, capabilities allow direct access to authorizations on the basis of the subject they refer to; it is expensive to retrieve all the accesses executable on an object because this operation requires the examination of all the different capabilities.
4 Authorization and Access Control 43
Ann David
read write
read Invoice1
Bob David
read write Invoice2
read write
Ann Carol
read Order1
Bob Carol
read Order2
read write
read write
Ann David
execute Program1
read Bob
execute
execute
Fig. 4.2.Access control lists corresponding to the access matrix in Fig. 4.1
Ann read write
Bob read write
execute Invoice1 Order1 Program1
read
Invoice2 Order2
execute Program1 read
Carol read write
David read
Order1 Order2 read
Invoice1 Invoice2
execute Program1 read
write
write
read
Fig. 4.3.Capability lists corresponding to the access matrix in Fig. 4.1
4.2.1 Enhanced Discretionary Policies
Although the access matrix still remains a framework for reasoning about accesses permitted by a discretionary policy, discretionary policies have been developed considerably since the access matrix was proposed. In particular, early approaches to authorization specifications allowed conditions [4] to be associated with authorizations to restrict their validity. Conditions can make the authorization validity dependent on the satisfaction of some system predi-cates, can make restrictions dependent on the content of objects on which the authorization is defined, or can make an access decision dependent on accesses previously executed. Another important feature supported by current discre-tionary policies is the definition of abstractions on users and objects. Both users and objects can therefore be hierarchically organized, thus introducing user groups andclasses of objects.
Figure 4.4(a) illustrates an example of a user group hierarchy and Fig. 4.4(b) illustrates an example of an object hierarchy. The definition of groups of users (and resources) leads to the need for a technique to easily handle exceptions. For instance, suppose that all users belonging to a group
44 S. De Capitani di Vimercati, S. Foresti, P. Samarati
Personnel
Sales
vv vv v
Production InfoSystem
MMMMM
Ann
Bob Carol
qq qq
q David
(a)
Resources
Documents
ss ss
s Programs
JJJJJ
Invoices
tt tt t
Orders
Invoice1
uu uu
u Invoice2 Order1 Order2
KKKKK
Program1 (b)
Fig. 4.4.An example of a user group hierarchy (a) and object hierarchy (b)
can access a specific resource but user u. In this case, it is necessary to as-sociate explicitly an authorization with each user in the group but u. This observation has been applied to the combined support of both positive and negativeauthorizations. In this way, the previous exception can easily be sup-ported by the definition of two authorizations: a positive authorization for the group and a negative authorization for user u. Hierarchies can also sim-plify the process of authorization definition because authorizations specified on an abstraction can be propagated to all its members. The propagation of authorizations over a hierarchy may follow different propagation policies [6].
We now briefly describe the most common propagation policies.
• No propagation.Authorizations are not propagated.
• No overriding.Authorizations associated with an element in the hierarchy are propagated to all its descendants.
• Most specific overrides.Authorizations associated with an element in the hierarchy are propagated to its descendants if not overridden. An autho-rization associated with an elementnoverrides a contradicting authoriza-tion (i.e., an authorizaauthoriza-tion with the same subject and object but with a different sign) associated with an ancestor ofnfor all the descendants of n. For instance, consider the user group hierarchy in Fig. 4.4(a) and sup-pose that there is a positive authorization for the InfoSystem group to read Order1, and a negative authorization for reading the same resource associated with Personnel. In this case, Carol will be allowed to read Order1, asInfoSystem is a more specific element in the hierarchy than Personnel.
• Path overrides. Authorizations of an element in the hierarchy are prop-agated to its descendants if not overridden. An authorization associated with an elementnoverrides a contradicting authorization associated with an ancestor n for all the descendants of n, only for the paths passing from n. The overriding has no effect on other paths. For instance, con-sider the user group hierarchy in Fig. 4.4(a) and suppose that there is a positive authorization for the InfoSystem group to read Order1, and a negative authorization for reading the same resource associated with Personnel. In this case, the negative authorization wins along the path
4 Authorization and Access Control 45 Personnel, Production, Carol; the positive authorization wins along the path Personnel, InfoSystem, Carol. Consequently, there is still a conflict for managing Carol’saccess toOrder1, as she inherits two con-tradicting privileges along the two paths reaching her.
The introduction of both positive and negative authorizations results in the following two problems: (i)inconsistency, which happens when conflicting authorizations are associated with the same element in a hierarchy; and (ii) incompleteness, which happens when some accesses are neither authorized nor denied (i.e., no authorization exists for them).
The inconsistency problem is solved by applying a conflict resolution pol-icy. There are different conflict resolution policies and we now briefly illustrate some of them [6, 7].
• No conflict.The presence of a conflict is considered an error.
• Denials take precedence.Negative authorizations take precedence.
• Permissions take precedence. Positive authorizations take precedence.
• Nothing takes precedence.Neither positive nor negative authorizations take precedence and conflicts remain unsolved.
The incompleteness problem can be solved by adopting a decision policy.
There are two main decision policies: (i) anopen policydenies access if there exists a negative authorization for it, and allows it otherwise; (ii) a closed policy allows access if there exists a positive authorization for it, and denies it otherwise. The combination of a propagation policy, a conflict resolution policy, and a decision policy guarantees a complete and consistent policy for the system.
4.2.2 Drawbacks of Discretionary Policies
Although discretionary policies are in general expressive and powerful, they have some drawbacks mainly due to the fact that they do not distinguish between users and subjects. Auser is a human entity whose identity is used by the access control module to identify her privileges on the system. Asubjectis instead a process generated by a user, which interacts with the system making requests on behalf of a user. Discretionary policies ignore this distinction and evaluate all requests submitted by a process running on behalf of some user against the authorizations of the user. This aspect makes discretionary policies vulnerable to processes executing malicious programs (e.g., Trojan horses) that exploit the authorizations of the user invoking them. In fact, discretionary access control policies leak control over the flow of information once data are acquired by a process.
For instance, consider the access matrix in Fig. 4.1 and suppose that David invokes an application hiding a Trojan horse. Since the application operates on behalf of David, it can read the content of Invoice2and write it on a new file, say Invoice3. Suppose also that this new file can be read
46 S. De Capitani di Vimercati, S. Foresti, P. Samarati
TS,{Financial,Economic}
TS,{Financial}
ii ii ii ii i
S,{Financial,EconomicUUUUUUUU} TS,{Economic} S,{Financial}
ii ii ii ii i
TS,{}
ii ii ii ii ii UUUUUUUUUU
S,{Economic}
UUUUUUUU
S,{}
UUUUUUUUUUU iiiiiiiiii Fig. 4.5.An example of a security lattice
byAnnandCarol. In this way, information inInvoice2is made readable to AnnandCarol.
Moreover, the security of a system based on discretionary access control is not easy to evaluate, due to the so-called safety problem, which is undecidable.