Print this chapterPrint this chapter

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

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

      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

Fig 4: Example of Trojan horse

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