In software design, the term “access control” refers to the limitations of access to resources by other entities, typically end-users. This is a very active area of research, and there’s a tremendous amount of useful discoveries in this space that software designers can apply to their applications.

In this article, we’ll go over some of the basic concepts involved when considering how to implement access controls within your software application.

Introduction

First, let’s define some terms:

• A resource – this is something you want to limit access to. It might be a file, a process, a device, or some functionality within a system.
• A principal – this is something that can be authenticated by the system. This can be an end user, an API grant, another computer, a group of users, etc.

The next question we should ask is, who is able to grant access from a given principal to a resource? As it turns out, there’s two major choices, the DAC model and the MAC model.

Discretionary access controls

Discretionary access controls (DAC) allow the owner of the resource to determine the access levels that each principal in the system will possess for the resource in question. For example, an end user may create a file, or a note, or some other resource in a system, and then they can assign other users read or write permissions to that file. The underlying premise is that the access controls are at the discretion of the owner. The term owner is a bit arbitrary here, but you could imagine it as being the principal who initially made the resource.

This is a very popular method of access control and one you’re probably very familiar with. Most of the SaaS applications I can think of utilize this model, and there’s a good reason – it’s simple to understand and it’s easy to obtain assurance as an end-user that permissions are correctly assigned. Further, it doesn’t require administrators to elevate or demote permissions on their behalf, and permissions can be defined quite granularly.

The downside of a DAC-based model is that the security is rather lax because users can share any data they like, to any level they like. This becomes a major problem when the number of users is large or the data ranges in sensitivity. For example, a top executive could accidentally share news about a pending acquisition to contractors outside of the organisation, jeopardizing the deal. And finally, it’s very hard to understand exactly who has access to what without going through and looking at each resource. This problem is very common with Google Drive, for example.

This really summarizes the core assumption of DAC – the owner knows best. If this is not true, then DAC is probably not the right choice. Here at Vokke, we implement DAC-based solutions when a simpler solution is needed and the security requirements are lower.

Mandatory access controls

Mandatory access controls (MAC) sit at the opposite end of the spectrum – all discretion is removed from the decision-making process. Under a MAC, access levels based on security clearance or attributes of the data, such as confidentiality level. Under a MAC model, even the creators of a resource cannot alter the security attributes of their files.

Enforcement of a MAC can happen inside the application itself, like in a DAC model, or even at a lower subsystem for greater assurance of security. For example, it’s not uncommon to have MACs implemented within the operating system or kernel itself, which provides some of the strongest guarantees of access control we know of.

Typically MACs are considered the most secure model and are used by military systems, government agencies, and commercial environments where iron-clad assurances need to be given on what data can be accessed and by who. Unfortunately, it’s not as user-friendly and often requires special system design in order to get right (if you want strong guarantees anyway). Further, and unlike a DAC, it does require an administrator who can define the security clearance levels that the system adopts.

At Vokke, we use AppArmor which is a Linux kernel security module that restricts the access particular programs have to the system. AppArmor is a MAC and can prevent a process from accessing particular system resources such as sockets, particular file locations, etc. Because this is done at the kernel level, even if there are flaws in the web application code itself there’s only so much an adversary can do given the operating system itself is enforcing a MAC profile over it.

So which model is the best?

As with most things, it depends on your requirements. If you are operating in a highly secure environment or dealing with mixed classification data then MAC is probably your best bet. If you’re building a software system for the SMB space then DAC may be more appropriate given it’s more easily understood by end-users.

But ultimately, these are just naming conventions we give to classify different access control models; you’ll note that the above descriptions provide no guidance as to how to implement them. Rather, they just help broadly define the solution space we’re in.

Over the next few posts, we’ll explore some actual, practical models of access controls that can be readily implemented in software.

Click here for the next article in the series: The Bell-LaPadula model.

Blog photo by Tommy Lee Walker on Unsplash.