Access Control Lists

An access control list (ACL) is a list of access control entries (ACE). Each ACE in an ACL identifies a trustee and specifies the access rights allowed, denied, or audited for that trustee. The security descriptor for a securable object can contain two types of ACLs: a DACL and a SACL.

A discretionary access control list (DACL) identifies the trustees that are allowed or denied access to a securable object. When a process tries to access a securable object, the system checks the ACEs in the object’s DACL to determine whether to grant access to it. If the object does not have a DACL, the system grants full access to everyone. If the object’s DACL has no ACEs, the system denies all attempts to access the object because the DACL does not allow any access rights. The system checks the ACEs in sequence until it finds one or more ACEs that allow all the requested access rights, or until any of the requested access rights are denied. For more information, see How DACLs Control Access to an Object. For information about how to properly create a DACL, see Creating a DACL.

A system access control list (SACL) enables administrators to log attempts to access a secured object. Each ACE specifies the types of access attempts by a specified trustee that cause the system to generate a record in the security event log. An ACE in a SACL can generate audit records when an access attempt fails, when it succeeds, or both. For more information about SACLs, see Audit Generation and SACL Access Right.

Do not try to work directly with the contents of an ACL. To ensure that ACLs are semantically correct, use the appropriate functions to create and manipulate ACLs. For more information, see Getting Information from an ACL and Creating or Modifying an ACL.

ACLs also provide access control to Microsoft Active Directory directory service objects. Active Directory Service Interfaces (ADSI) include routines to create and modify the contents of these ACLs. For more information, see Controlling Access to Active Directory Objects.

Access Control List

An access control list (ACL) is a list of ACEs created by the operating system to control the security behavior associated with a given (protected) object of some sort. In Windows there are two types of ACLs:

Discretionary ACL—this is a list of zero or more ACEs that describe the access rights for a protected object. It is discretionary because the access granted is at the discretion of the owner or any user with appropriate rights.

System ACL—this is a list of zero or more ACEs that describe the auditing and alarm policy for a protected object.

The term «discretionary» refers to the differentiation between mandatory and discretionary control. In an environment that uses mandatory controls, the owner of an object may not be able to grant access to the object. In a discretionary environment, such as Windows, the owner of an object is allowed to grant such access. Mandatory controls are normally associated with very tight security environments, such as those using compartmentalized security, where the system must prevent disclosure of sensitive information between users on the same system.

A driver constructing an ACL would follow a few key steps:

Allocate storage for the ACL.

Initialize the ACL.

Add zero (or more) ACEs to the ACL.

The following code examples demonstrate how to construct an ACL:

The previous code fragment creates an empty ACL. The code sample allocates a significant amount of memory, since we do not know the size required for the ACL.

At this point, the ACL is empty because it has no ACE entries. An empty ACL denies access to anyone trying to access the object because there are no entries that grant such access. The following code fragment adds an ACE to this ACL:

This entry would now grant access to any entity that accessed the object. This is the purpose of world access SID (SeWorldSid), which is usually represented as «Everyone» access in other Windows system utilities.

Note that when constructing ACLs, it is important to order access denied ACE entries at the beginning of the ACL, and then access allowed ACE entries at the end of the ACL. This is because when the security reference monitor does the evaluation of the ACL it will grant access if it finds an ACE granting access, before it finds the denied ACEs. This behavior is well documented in the Microsoft Windows SDK, but it relates to the specific mechanism the security reference monitor uses to determine whether access should be granted or denied.

ACL structure (winnt.h)

The ACL structure is the header of an access control list (ACL). A complete ACL consists of an ACL structure followed by an ordered list of zero or more access control entries (ACEs).

Syntax

Members

Specifies the revision level of the ACL. This value should be ACL_REVISION, unless the ACL contains an object-specific ACE, in which case this value must be ACL_REVISION_DS. All ACEs in an ACL must be at the same revision level.

Specifies a zero byte of padding that aligns the AclRevision member on a 16-bit boundary.

Specifies the size, in bytes, of the ACL. This value includes both the ACL structure and all the ACEs.

Specifies the number of ACEs stored in the ACL.

Specifies two zero-bytes of padding that align the ACL structure on a 32-bit boundary.

Remarks

An ACL includes a sequential list of zero or more ACEs. The individual ACEs in an ACL are numbered from 0 to n, where n+1 is the number of ACEs in the ACL. When editing an ACL, an application refers to an ACE within the ACL by the ACE’s index.

There are two types of ACL: discretionary and system.

A discretionary access control list (DACL) is controlled by the owner of an object or anyone granted WRITE_DAC access to the object. It specifies the access particular users and groups can have to an object. For example, the owner of a file can use a DACL to control which users and groups can and cannot have access to the file.

An object can also have system-level security information associated with it, in the form of a system access control list (SACL) controlled by a system administrator. A SACL allows the system administrator to audit any attempts to gain access to an object.

For a list of currently defined ACE structures, see ACE.

A fourth ACE structure, SYSTEM_ALARM_ACE, is not currently supported.

The ACL structure is to be treated as though it were opaque and applications are not to attempt to work with its members directly. To ensure that ACLs are semantically correct, applications can use the functions listed in the See Also section to create and manipulate ACLs.

Each ACL and ACE structure begins on a DWORD boundary.

The maximum size for an ACL, including its ACEs, is 64 KB.

Access Control Overview

Applies to

• Windows 10
• Windows Server 2016

This topic for the IT professional describes access control in Windows, which is the process of authorizing users, groups, and computers to access objects on the network or computer. Key concepts that make up access control are permissions, ownership of objects, inheritance of permissions, user rights, and object auditing.

Feature description

Computers that are running a supported version of Windows can control the use of system and network resources through the interrelated mechanisms of authentication and authorization. After a user is authenticated, the Windows operating system uses built-in authorization and access control technologies to implement the second phase of protecting resources: determining if an authenticated user has the correct permissions to access a resource.

Shared resources are available to users and groups other than the resource’s owner, and they need to be protected from unauthorized use. In the access control model, users and groups (also referred to as security principals) are represented by unique security identifiers (SIDs). They are assigned rights and permissions that inform the operating system what each user and group can do. Each resource has an owner who grants permissions to security principals. During the access control check, these permissions are examined to determine which security principals can access the resource and how they can access it.

Security principals perform actions (which include Read, Write, Modify, or Full control) on objects. Objects include files, folders, printers, registry keys, and Active Directory Domain Services (AD DS) objects. Shared resources use access control lists (ACLs) to assign permissions. This enables resource managers to enforce access control in the following ways:

Deny access to unauthorized users and groups

Set well-defined limits on the access that is provided to authorized users and groups

Object owners generally grant permissions to security groups rather than to individual users. Users and computers that are added to existing groups assume the permissions of that group. If an object (such as a folder) can hold other objects (such as subfolders and files), it is called a container. In a hierarchy of objects, the relationship between a container and its content is expressed by referring to the container as the parent. An object in the container is referred to as the child, and the child inherits the access control settings of the parent. Object owners often define permissions for container objects, rather than individual child objects, to ease access control management.

Access Control List (ACL)

Learning Objectives

• Understand the concept of ACL
• Discover ACL types
• Learn about Linux vs Windows ACL
• Get ACL best practices
• Understand RBAC vs ACL

What Is an Access Control List

An access control list (ACL) contains rules that grant or deny access to certain digital environments. There are two types of ACLs:

• Filesystem ACLs━filter access to files and/or directories. Filesystem ACLs tell operating systems which users can access the system, and what privileges the users are allowed.
• Networking ACLs━filter access to the network. Networking ACLs tell routers and switches which type of traffic can access the network, and which activity is allowed.

Originally, ACLs were the only way to achieve firewall protection. Today, there are many types of firewalls and alternatives to ACLs. However, organizations continue to use ACLs in conjunction with technologies like virtual private networks (VPNs) that specify which traffic should be encrypted and transferred through a VPN tunnel.

Reasons to use an ACL:

• Traffic flow control
• Restricted network traffic for better network performance
• A level of security for network access specifying which areas of the server/network/service can be accessed by a user and which cannot
• Granular monitoring of the traffic exiting and entering the system

How ACL Works

A filesystem ACL is a table that informs a computer operating system of the access privileges a user has to a system object, including a single file or a file directory. Each object has a security property that connects it to its access control list. The list has an entry for every user with access rights to the system.

Typical privileges include the right to read a single file (or all the files) in a directory, to execute the file, or to write to the file or files. Operating systems that use an ACL include, for example, Microsoft Windows NT/2000, Novell’s Netware, Digital’s OpenVMS, and UNIX-based systems.

When a user requests an object in an ACL-based security model, the operating system studies the ACL for a relevant entry and sees whether the requested operation is permissible.

Networking ACLs are installed in routers or switches, where they act as traffic filters. Each networking ACL contains predefined rules that control which packets or routing updates are allowed or denied access to a network.

Routers and switches with ACLs work like packet filters that transfer or deny packets based on filtering criteria. As a Layer 3 device, a packet-filtering router uses rules to see if traffic should be permitted or denied access. It decides this based on source and destination IP addresses, destination port and source port, and the official procedure of the packet.

Types of Access Control Lists

Access control lists can be approached in relation to two main categories:

Standard ACL
An access-list that is developed solely using the source IP address. These access control lists allow or block the entire protocol suite. They don’t differentiate between IP traffic such as UDP, TCP, and HTTPS. They use numbers 1-99 or 1300-1999 so the router can recognize the address as the source IP address.

Extended ACL
An access-list that is widely used as it can differentiate IP traffic. It uses both source and destination IP addresses and port numbers to make sense of IP traffic. You can also specify which IP traffic should be allowed or denied. They use the numbers 100-199 and 2000-2699.

Linux ACL vs. Windows ACL

Linux provides the flexibility to make kernel modifications, which cannot be done with Windows. However, because you can make kernel modifications to Linux, you may need specialized expertise to maintain the production environment.

Windows offers the advantage of a stable platform, but it is not as flexible as Linux. In relation to application integration, Windows is easier than Linux.

A user can set access control mechanisms in a Windows box without adding software.

In terms of patching, Microsoft is the only source to issue Windows patches. With Linux, you can choose to wait until a commercial Linux provider releases a patch or you can go with an open-source entity for patches.

ACL Best Practices

When configuring ACLs, you should adhere to a few best practices to ensure that security is tight and suspicious traffic is blocked:

1. ACLs everywhere
ACLs are enforced on each interface, in nearly all security or routing gear. This is fitting as you can’t have the same rules for outward-facing interfaces and interfaces that form your campus network. However, interfaces are similar and you don’t want some protected by ACLs and some exposed.

The practice of an ACL on all interfaces is essential for inbound ACLs, specifically the rules that decide which address can transfer data into your network. Those are the rules that make a considerable difference.

2. ACL in order
In almost all cases, the engine enforcing the ACL begins at the top and moves down the list. This has implications for working out what an ACL will do with a specific data stream.

One reason organizations adopt ACLs is that they have a lower computational overhead than stateful firewalls and that they work at high speeds. This is essential when you try to implement security for fast network interfaces. However, the longer a packet remains in the system, while it is examined against the rules in the ACL, the slower the performance.

The trick is to put the rules that you expect will be triggered at the top of the ACL. Work from the general to specific, while ensuring the rules are logically grouped. You should know that each packet will be acted on by the initial rule that it triggers, you could end up passing a packet via one rule when you intend to block it via another. Consider how you want the chain of events to happen, in particular when adding new rules.

3. Document your work
When you add ACL rules, document why you are adding them, what they are intended to do, and when you added them.

You don’t need to have one comment per rule. You can make one comment for a block of rules, an intricate explanation for a single rule, or a combination of both approaches.

Developers should ensure that the current rules are documented, so nobody needs to guess why a rule is there.

RBAC vs ACL

Developers can use role-based access list (RBAC) systems to control security at a granular level. Rather than emphasizing the identity of the user and determining whether they should be permitted to see something in the application, RBAC governs security based on the role of the user within an organization.

For example, rather than giving permission to John Smith, an architect in New York, RBAC would give permission to a role for U.S. architects. John Smith may be one of many users with that role. Thus, RBAC guarantees regulatory persons that only specific users have access to sensitive information, as it gives all approvals based on roles.

RBAC is generally considered to be a preferred method for business applications. RBAC is more effective than ACL in relation to administrative overheads and security. ACL is best used for applying security at the individual user level. You can use RBAC to serve a company-wide security system, which an administrator monitors. An ACL can, for example, provide write access to a certain file, but it cannot define how a user can modify the file.

Example of a role-based access control (RBAC) system

Role-Based Access Control with Imperva

Imperva allows for control of user privileges using flexible role-based access controls. Users are provided with view-only, edit, or restricted access to management functions and objects. Organizations can also hierarchically group and manage IT assets into categories for fine-grained access control, even in Managed Security Service Provider (MSSP) deployments and large-scale enterprise.