Discretionary access control is used widely in our connected world, from social media to smartphones. But how secure is it in reality?
The security world calls it discretionary access control. Laypersons and users just call it setting permissions. It's simple, user-friendly, and everywhere. We find it in our smartphones, our social media apps, and our office suites. But did you know that it comes with risks to your business' security and your users' privacy?
In this article, we'll understand what access control is, what discretionary access control is, how and when it's used, its benefits and drawbacks, and using two case studies, its security risks in a world where cloud and online services are popular.
Basics of Access Control
An object is any type of resource or entity relevant to a software system. Files in a file system, virtual machines in the cloud, and videos uploaded to a YouTube account are all objects.
Each object supports some actions like editing a file or publishing a video. Permissions grant the ability to perform certain actions on an object.
A subject is an agent that's interested in accessing an object. Human users, web applications, desktop applications, mobile apps, devices, or third-party services are all subjects.
Access control refers to the management of permissions on objects and their grants to subjects.
Access Control Models
An access control policy defines an organization's rules for configuring secure access control. A policy is based on one of the available access control models.
An access control model or access control system is a template of principles, concepts, and actions that forms the basis for an access control policy. Some of the popular types of access control are introduced below.
Discretionary Access Control (DAC)
We'll explain DAC in detail in the rest of the article.
Mandatory Access Control (MAC)
In MAC, system administrators centrally configure security mandates that end users can't change or override, and these mandates typically require security labels on the subject and the object to match.
For example, the US Department of Defense (DoD) uses clearance levels — like top secret and confidential — as security labels for documents and mandates that only personnel with matching clearance levels can access.
Role-based Access Control (RBAC)
In RBAC, users are grouped under a relatively small set of roles. Permissions are assigned to the roles instead of individual users. It's a way of organizing a large number of users into a small number of groups for administrative convenience. The roles often correspond to levels in the business's organizational structure, such as job roles or departments.
Attribute-based Access Control (ABAC)
In ABAC, access rules are defined and evaluated based on the security attributes of both the subject and the object. ABAC is centrally administered just like MAC and RBAC but is more flexible than them. It recognizes that security attributes that are complex and dynamic may be necessary for user access. For example, dynamic variables like a user's current location, time, and device may be used to decide permissions.
Rule-based Access Control
In this model, the access control depends not just on attributes of the subject and the object but also on rules about their external environment and context. For example, an organization may restrict access to a file after 6 p.m. Rule-based access control can be implemented by combining any of the other access models with additional rules.
Hybrid Models
It's not unusual for software or SaaS to combine two or more access control models. If a system anticipates large numbers of users, it often implements both DAC and RBAC to make granting permissions convenient for both system administrators and end-users. Additional policies negotiate any conflicting rules between the underlying models.
What Is Discretionary Access Control?
In the DAC system, an object owner has full control over object access and is free to assign permissions to other users at their discretion.
In many DAC systems, users are allowed to assign additional access rights to objects even if they don't own them.
DAC implementations can store access rights with either the object or the subject.
In an access control list (ACL) implementation, the access rights to an object are stored with that object as a list of subjects and granted permissions.
In a privilege list implementation, the access rights of a subject are stored with that subject as a list of objects it can access and the permissions granted to it on each of them.
The implementation affects factors like system performance. If a practically unbounded number of objects — like files in a file system — can exist, privilege lists are not a good approach because deleting an object requires deletion from multiple privilege lists. Privilege lists work well only when subjects and objects are few.
DAC Examples
DAC is ubiquitous in our software and devices. It's found in operating systems like Windows, Linux, and Unix. It's found in file systems. Let's see some DAC examples your users are likely to run into every day.
Windows Operating System
DAC in Windows file explorer
The Windows 11 file permissions dialog is a good example of an ACL-based DAC system. For a selected file or folder, it shows a list of subjects (users) at the top and the object-level permissions granted to each subject.
Smartphones
DAC permissions in a smartphone app
Both Android and iOS smartphone apps follow a DAC permissions model using privilege lists. The permissions are to your data — like your contacts or location — or the phone's capabilities — like using the camera or making calls. Each app is a separate subject that you assign data or capability permissions. These are stored as the app's privilege list.
How Is DAC Used?
All DAC implementations have some characteristic features and behaviors:
Each resource (object) in the system — a file, a document, or a cloud resource — has an associated ACL.
The user can open a user interface on each resource to examine or modify its ACL.
The user can add other users who should have access to that resource.
The user can enable or disable permissions to themselves or other users.
For most online services, the user can get a special link to a resource. The link can be shared with other people to let them access that resource.
4 Benefits of DAC
DAC has several benefits both for users and SaaS providers.
1. User-friendly
DAC's simplicity — assign permissions to users — makes it intuitive and user-friendly to all end users, even those who aren't tech-savvy.
2. Popular
The term, DAC, may not be popular outside security circles but it is the most popular permissions model out there. Smartphones and popular apps have conditioned everybody to understand it intuitively. Top apps like Facebook, YouTube, and Instagram all follow this model for their security and privacy settings. So do business and collaboration services like LinkedIn and Google Workspace.
3. Fine-grained
DAC supports customized permissions for every user while keeping the user experience friendly and intuitive. Other access models like ABAC too support fine-grained permissions but their user experiences are not as convenient.
4. Easy to Implement
If you're a SaaS or other service provider, you'll find it easy to implement DAC for the objects in your system. Both the database design and the user interfaces for DAC are easy to implement.
6 Security Drawbacks of DAC
From a cybersecurity perspective, DAC brings some security risks and administrative inconveniences to your business.
1. Easy to Breach the Principle of Least Privilege
The principle of least privilege expects your employees to get just the minimum necessary permissions they need to carry out their tasks. Ideally, this should be true all the time. However, most DAC implementations make it convenient to assign all permissions and usually don't provide any mechanism to automatically revert the permissions.
2. Users Prioritize Convenience Over Security
Most users prefer convenience over security. For example, if three or more employees need to collaborate on a document, many document owners will grant everyone access to the document. It's much faster to just check a single checkbox that grants it to everyone over adding three email addresses and three sets of permissions. Regular training is necessary to help your employees balance convenience with security concerns.
3. Anyone Can Set Permissions
The idea of giving everybody the ability to set permissions is inherently insecure. It's like giving the keys to the house, along with a key machine, to every visitor.
4. Difficult To Administer at Scale
The ability of users to distribute permissions without limits makes it difficult for security teams and system administrators to maintain control over computer security and data security. Many DAC implementations don't provide the administrative features to do it. Approaches like automated security workflows using additional software like security orchestration, automation, and remediation (SOAR) are needed to administer DAC systems at scale.
5. Difficult to Monitor
When permissions are granted or modified, many DAC systems don't provide a way to notify those changes to the organization's system administrators or security teams. They're kept in the dark about the set of all objects and permissions that exist and impact the organization's overall security state.
6. Granted Permissions Are Not Revoked
A big risk of DAC is that after permissions are granted, they are often forgotten while an object carries those permissions for years. If a malicious attacker takes over an employee's, or former employee’s, email address through phishing, they may be able to access sensitive data of an organization.
When Should You Use DAC?
Knowing these benefits and drawbacks, when should you use DAC? This question may come up in two contexts — in a security context or a SaaS architecture context.
In a security context, your company’s security team may have to decide whether to enable or disable the DAC permissions of some service you’re subscribed to. If your employees are not tech-savvy, the tradeoff is between convenience plus efficiency versus security. A service that provides both DAC and RBAC and allows centralized RBAC policies to override DAC permissions would be ideal. You should conduct regular security assessments if DAC systems are widely used in your organization.
In a SaaS architecture context, if your startup is a SaaS provider, you have to decide whether implementing DAC without sufficient safeguards endangers the cybersecurity of your customers. You should be ready to implement security controls — like centrally configurable RBAC and permission revocation — and auditing capabilities to help your customers’ security teams gain confidence in your service’s security.
Cloud Case Study: DAC in Google Docs
Permissions and sharing in Google Docs
For our first case study, we'll explore Google Docs, a service that has users from all walks of life with varying levels of tech-savviness. Google Docs Editors is a suite of online collaboration tools for authoring documents, spreadsheets, and presentations. It's also part of Google Workspace for businesses. Its DAC system has the following features and behaviors:
Six basic actions are permitted on a document — read, comment, write, download, copy, and print.
Two security actions are available on a document — set permissions and share.
The user interface hides these permissions behind three user-friendly levels of access — viewer, commentator, and editor. A user can be assigned one of these levels.
A viewer gets read, copy, download, and print permissions. The owner can choose to disable the latter three for all viewers.
A commentator gets all viewer permissions plus commenting permission.
An editor is permitted to all six basic actions and the two security actions. The owner can choose to disable security actions for all editors.
To collaborate on a document with other users, its document owner adds their email addresses and sets their permission levels.
When a large number of unknown users have to collaborate, adding them individually is inconvenient. Instead, the owner and editors can collaborate with all contacts in a contact group, or with anyone in the world, by simply sharing an appropriate link with them. Each group and the world get one of the same three permission levels.
Security Risks
Google Docs provides some security protections. An audit log reports all user and permissions activity for human eyes and security tools. File exposure reports and data loss prevention rules help monitor security and implement data security.
But despite all that, we can see some of DAC's drawbacks are present in Docs:
Email addresses and links are the authentication mechanisms. But both are highly vulnerable. Email addresses are prone to phishing and takeover. Links are prone to sharing and spreading.
The editor permission level is the riskiest because it enables a user to pass on permissions and links to anyone in the world. The riskiest configuration is assigning editor permissions to anyone with the link. We recommend that owners disable the ability of editors to set permissions and share.
The “anyone with a link” option is available for convenience. Many users prefer it over adding users individually because it saves time. However, its use results in a drastic expansion in your organization's attack surface — the set of all things that can be attacked by cyber threats.
Docs does not provide any built-in mechanism to automatically revoke permissions after a set time or if a link hasn't been accessed for some number of days. Such measures require additional external software.
Cloud Case Study: DAC in Amazon S3
Amazon S3’s DAC ACL configuration
Amazon S3 is Amazon's cloud storage service for storing large volumes of any kind of data. Unlike Google Docs, S3 is mostly used programmatically by applications. Software and DevOps engineers may sometimes manually interact with it. Let's understand its DAC implementation.
S3 has two concepts — buckets and objects. An object is an item containing data, similar to a file. A bucket is a collection of closely-related objects. For example, a bucket is created for a photo album and each photo in it is stored as an object.
A bucket has a bucket owner and each object can have its object owner. S3 supports a large number of actions on buckets and objects — create a bucket, list a bucket, delete a bucket, put an object into a bucket, retrieve it, update it, and so on.
In its early years, S3 access control was a DAC model with ACLs. Bucket and object owners were free to assign permissions at their discretion. Later, due to DAC's security risks, it moved away from DAC to a policy-based model that organizations can control centrally. S3 still supports ACLs for legacy reasons but recommends the new access model for new buckets.
Security Risks
Some security risks of S3's DAC model:
For convenience, it's possible to configure public access to an entire bucket and all objects in it.
Enabling cross-account access to another Amazon Web Services account allows that account to pass on its permissions to all users under it.
A combination of inherent complexity, insecure default settings, misconfigurations, and difficult documentation have resulted in many S3 data breaches. Data breaches due to misconfigured S3 buckets continue to make it to the news regularly.
How ThreatKey Protects You From Discretionary Access Control Risks
Most of these services provide discretionary access control and role-based access control features to your employees. As the case studies show, users can easily misconfigure permissions and inadvertently expand your organization's attack surface.
ThreatKey flags and alerts you when any configuration that impacts overall discretionary access control of a service is changed.
ThreatKey also analyzes all your configurations and your logs to detect potential security risks and signs of exploited security risks. It reports any problems it finds to you. With your permission, it can automatically remediate them too.
Discretionary Access Control: User-friendly but Tread With Caution
An access control model's purpose is to effectively prevent a range of cyber threats. A discretionary access control model can do that while being both user-friendly and implementation-friendly. But it can also lull both your users and your organization into complacency about security and turn security policy into security theater.
To keep your access control effective, use a service like ThreatKey that continually monitors it for misconfigurations. Try ThreatKey for free today.
.svg)
