Mandatory Access Control (MAC) and Discretionary Access Control (DAC)

Discretionary Access Control (DAC)

Specify the rules under which subjects can, at their discretion, create and delete objects and grant and revoke authorizations for accessing objects to others [6]. That is:

Govern the access of users to information on the basis of the user's identity and predefined discretionary rules defined by the security administrator.

The rules specify, for each user and object in the system, the types of access the user is allowed for the object.

The request of a user to access an object is checked against the specified authorizations; if there exists an authorization stating that the user can access the object in the specific mode, the access is granted; otherwise, it is denied. The policies are discretionary in that they allow users to grant other users authorizations to access the objects.

Discretionary policies are used in commercial systems for their flexibility, which makes them suitable for a variety of environments with different protection requirements.

Discretionary models are applied in relational database systems using System R Authorization Model and some extensions to it.

 

The System R Authorization Model

This model is first defined by Griffiths and Wade and later revised by Fagin. Possible relational database privileges users can exercise on tables are select, insert, delete, and update.

The model supports decentralized administration of authorizations. Any database user is authorized to create a new table; once the table is created he becomes the owner of the table and is fully authorized to exercise all privileges on the table. The owner can also grant all privileges on the table to other users.

The authorization can be modeled as a tuple of the form < s, p, t, ts, g, go> stating that the user s has been granted privilege p on table by user g at time ts. If go=yes, s has the grant option and, therefore, s is authorized to grant other users' privilege p on table t, with or without grant option. Every time a privilege is revoked from a user, a recursive revocation may take place to delete all authorizations which would have not existed had the revokee never received any authorizations for the privilege on the table from the revoker.

To illustrate this concept, consider the consequence of grant operations for privilege p on table t illustrated in fig. 2(a), where every node represents a user and an arc between node u1 and u2 indicates that u1 granted the privilege on the table to u2. The label of the arc indicates the time the privilege was granted.

Suppose now Bob revokes the privilege on the table from David. According to the semantics of recursive revocation, since David has never received authorization from Bob, David could not have granted the privilege to Ellen and Ellen to Jim. However, in the diagram authorization from David to Frank does not have to be deleted because it may be granted by Chris. The set of authorizations holding in the system after the revocation is shown in fig. 2(b).

Fig 2: Bob revokes the privilege from David

• Extensions to the System R Model

  The previous model was extended by Wilms and Lindsay to simplify the management of

  authorizations [6]. They have included the authorizations for group. Group is a set of users or other groups. Group is disjoint i.e. a user or a group may belong to more than one group. Authorizations specified for group, means that they are valid for all members of the group.

  The two main extensions are as follows:

  • A new type of REVOKE operation, called non- cascading is introduced. Suppose now if Bob invokes the non-cascading revoke operation on the privilege granted to David, the authorization given by David to Ellen and Frank are re-specified with Bob as grantor and Jim retains the authorization given him by Ellen as shown in fig. 3(b).

  • The system R model uses closed world policy under which when a user tries to access a table and if positive authorization is not found, the user is denied access. The major problem with this approach is that a user does not guarantee that he will not acquire the authorization anytime in the future. The use of explicit negative authorizations can overcome this drawback. According to which if a user has both negative and positive authorization for a given privilege in the same table; the user is prevented from using the privilege on the table.
    
    

    

    Fig 3: Bob revokes the privilege from David without cascade

• Trojan Horse Attacks

  The main drawback of DAC is that although each access is controlled and allowed only if authorized, it is possible to bypass the access restrictions stated through the authorizations. A subject who is able to read data can pass the data to other subjects not authorized to read the data without the cognizance of the data owner [15]. This weakness makes DAC vulnerable to malicious attacks such as Trojan Horses [6] [8].

  A Trojan horse is a computer program with an apparently or actually useful function, which contains additional hidden functions that surreptitiously exploit the legitimate authorizations of the invoking process. The Trojan Horse Attacks can be understood by the example of an organization. Suppose a top-level manager named Ann creates a table market containing sensitive information. Tom, one of Anns subordinate, who also works secretly for another organization wants this information. To achieve this, Tom secretly creates a table stolen and gives write privilege to Ann on this table. Ann doesn't even know about the existence of this table and having privilege on the table. Tom also secretly modifies worksheet application to include two hidden operations:

  • A read operation on the table market.

  • A write operation on the table stolen.

    As shown in fig. 4(a). Tom then gives this new application to his manager Ann. As a result during execution, sensitive information is copied from the market to stolen and becomes available to dishonest employee Tom who can now misuse this information (fig. 4(b)).
    
    

Fig 4: Example of Trojan horse

---

Source: Indu Kashyap Kriti, https://www.ijert.org/database-security-access-control-models-a-brief-overview
This work is licensed under a Creative Commons Attribution 4.0 License.

Mandatory Access Control (MAC)

MAC security policies govern the access on the basis of the classifications of subjects and objects in the system [6]. Objects are the passive entries storing information for example relations, tuples in a relation etc. Subjects are active entities that access the objects, usually, active processes operating on behalf of users.

An access class consists of two components: a security level and a set of categories.

The security level is an element of a hierarchically ordered set. The levels often considered are Top Secret (TS), Secret (S), Confidential (C) and Unclassified (U), where TS>Sgt;C>U.

The set of categories is an unordered set, for example, NATO, Nuclear, Army etc.

The security level of the access class associated with an object reflects the sensitivity of the information contained in the object which means the potential damage which could result from unauthorized disclosure of information [7]. The security level of the access class associated with a user is called clearance, which reflects the users trustworthiness not to disclose sensitive information to users not cleared to it.

Access control in mandatory protection systems is based on the following two principles:

• No read-up/Read down: A subject can read only those objects whose access class is dominated by the access class of the subject.

• No write-down/Write up: A subject can write only those objects whose access class dominates the access class of the subject.

Satisfaction of these principles prevents information that is more sensitive to flow to objects at lower levels hence prevents the confidentiality of sensitive information. The effect of these rules can be diagrammatically represented as shown in fig. 5.

Fig 4: Example of Trojan horse

Fig 5: Controlling information flow for secrecy

MAC can as well be applied for the protection of information integrity [7]. For example, the integrity levels could be Crucial (C), Important (I)

and Unknown (U). The integrity level associated with an object reflects the degree of trust that can be placed in the information stored in the object, and the potential damage that could result from unauthorized modification of the information. The integrity level associated with a user reflects the user's trustworthiness for inserting, modifying, or deleting data programs at that level. The principles that are required to hold are as follows.

• Read up - A subject's integrity level must be dominated by the integrity level of the object being read.

• Write down - A subject's integrity level must dominate the integrity level of the object being written.

The effect of these rules can be diagrammatically represented as shown in fig. 6.

MAC models are not vulnerable to Trojan horse attacks: Consider fig. 4, if Tom is not allowed read access to table Market, under MAC control, table Market will have an access class that is either higher than or incomparable to the access class given to Tom. But then a subject able to read Market would not be able to write table Stolen and hence Trojan horse would not be able to complete its function.