Access Control: 10000 foot view

Feb 28, 2018

Overview

Access control has different facets like authentication, authorization and audit. Here we look at some common access control models with the focus on authorization. This post is about the points you should consider when you design a model of granting permission to access a resources.

Concepts

Before looking at some common models, we look at the access control concepts and perspectives.

Capability-based security

A capability is formally defined as an unforgeable token of authority that references an object along with an associated set of access rights. A file name is an example of a forgeable reference because it identifies an object but does not specified the required rights to access the file. Passing the file name to a service that has more rights than the user process requires validation before the service can access the file. On the other hand, if the user opens the file and passes a kind of file descriptor, the service can use that file descriptor directly. That is an unforgeable reference.

Most operating systems are not capability-based in the strict sense. Fuchsia and CapROS are few capability-based operating systems being actively developed.

Confused deputy problem

The confused deputy problem is a special case of privilege escalation. If in the example above, the service having more rights that the user process does not validate that the process has required rights, it is a security leak that can be exploited by passing for example a path to a file, that the user process does not have rights for.

The capability-based systems protect against this problem, whereas access control list alone do not.

Principle of least privilege

This principle requires that in a user process must be able to access only the resources that are necessary for its purpose. In other words, do not give the process more rights than it needs to have to work correctly.

Mandatory and discretionary models

In mandatory access control (MAC) , the constraints of the ability of a subject to access a resource are embedded into the (operation) system. Discretionary access control (DAC) restricts access to resources based on the identity of subjects or groups they belong to. Usually, MAC and DAC are implemented simultaneously. Purely discretionary access control might mean lack of MAC.

Separation of duties

Sometimes the system requires more than one subject to perform a task. This concept is called separation of duties. The application areas could be prevention of fraud or error.

Models

Access control lists (ACL)

Permissions are directly attached to the resource. An ACL specifies which user is allowed to access resource and what operation to execute (for example read or write). Some ACLs might consist of a list of allow and deny conditions whereby the first matched condition wins.

Capability sets

Policies are defined as sets of capabilities. A capability is a positive permission to perform an action. Comparing to ACL, capability sets are simpler and more straight forward to implement.

Role-based access control (RBAC)

This model is very popular and used by lots of enterprises. Permissions are assigned not directly to the users (subjects) but to the roles. The users are assigned to the roles. This indirection allows fine grained access control and comfortable overview of the current assigned permissions.

Attribute-based access control (ABAC)

If the final set of permissions in RBAC is a union of permissions of assigned roles, in attribute-based access control the final permission set is computed by evaluating a set of rules applied on multiple attributes attached to the object, subject, action or context. So we can see RBAC as a subset of ABAC with the single rule unionOfPermissionsOfAssignedRoles. This model gets much attention in the last years.

Graph-based access control (GBAC)

This model uses a declarative way to define permissions. Different resources and their relations are described in a graph. The final permission set is calculated by executing a query in a specific language applied on the resource graph.

Implementations and standards

XACML

https://en.wikipedia.org/wiki/XACML XACML is a declarative attribute-based policy language. It is based on XML. There is a JSON representation containing XML namespaces. It contains three element levels: policy set, policy and rule. There are several algorithms defined to deal with conflicts in the policies. There are functions like anyOf, allOf, etc. These traits make the languages quite complex.

There are a couple of implementations of XACML. The majority of implementations are done in Java.

AWS IAM

The language is used to restrict access to AWS resources. A policy consists of a list of statements concatenated by a logical OR operation. Each statement has

  • Effect – whether the policy allows or denies access.
  • Action – the list of actions that are allowed or denied by the policy.
  • Resource – the list of resources on which the actions can occur.
  • Condition (Optional) – the circumstances under which the policy grants permission.

For further details see here.

Conclusion

There is a bunch of different access control principles and models. There is no the right way to restrict the access but a set of guide lines. In the last years, the attribute-based access control gains popularity.