SetACL Windows Permission Management

From an application packaging point of view, 'Permission Manipulation' is a vital part of the process. Application packagers know how to manipulate permissions (like Lock Permissions) using Wise Package Studio directly or by using the SetACLs tool. Here's a little background info.

This edited topic talks about the SetACLs tool which is normally used for manipulating permissions, or, to be more exact, security descriptors (SDs). This information is collected through various web sources.

What does SetACL stand for?

SetACL is a tool for manipulating permissions, or, security descriptors (SDs). SDs are used on operating systems based on Windows NT to control access to securable objects.

What is a securable object?

Every object that can have an SD is a securable object. All named and several unnamed Windows objects are securable and can have SDs, although this is not widely known. There is not a GUI for manipulating the SDs of many object types. Have you ever tried to kill a system process in Task Manager and got the message "Access denied"? This is due to the fact that the process' SD does not allow even administrators to kill the process. But it is, of course, possible, as an administrator, to obtain the necessary permissions, provided a GUI or some other tool is available.

Among several others, the following object types are securable:

• Files and directories on NTFS volumes
• Registry keys (but not values)
• Network shares
• Printers
• Services
• Active Directory objects
• Processes

What is a security descriptor (SD)?

A security descriptor is a binary data structure that contains all information related to access control for a specific object. An SD may contain the following information:

• The owner of the object
• The primary group of the object (rarely used)
• The discretionary access control list (DACL)
• The system access control list (SACL)
• Control information

Let us have a look at the first property, the owner. This could be any user, group or even computer account. As you might have guessed, it is rather tedious to write "user/group/computer" when talking about the account that is holding a certain permission. For this reason the term "trustee" is used instead.

A few words about security IDs (SIDs)

Any trustee can be identified by its name or by its SID. Humans tend to prefer names whereas computers very much prefer SIDs, which are binary data structures. When humans cannot avoid dealing with SIDs they use a certain string format. In this format, the SID of the local group "Administrators" looks like this: S-1-5-32-544.

It is important to remember that trustees referenced in SDs are always stored as binary SIDs. This is true for the owner, the primary group and any trustee in any access control list (ACL). This implies that there exists some mechanism which converts trustee names into SIDs and vice versa. This mechanism is a central part of the security accounts manager (SAM) and Active Directory (AD). The former manages the account database on any NT based system (NT workstations, servers and domain controllers, Windows 2000, XP, ...). The latter is only available on Active Directory Domain Controllers where it replaces the SAM.

Owner

An object can, but need not have, an owner. Most objects do, though. The owner of an object has the privilege of being able to manipulate the object's DACL regardless of any other settings in the SD.

Primary Group

The primary group of an object is rarely used. Most services and applications ignore this property.

Discretionary access control list (DACL)

The DACL is controlled by the owner of the object and specifies what level of access particular trustees have to the object. It can be NULL or nonexistent (no restrictions, everyone full access), empty (no access at all), or a list, as the name implies. The DACL almost always contains one or more access control entries (ACEs). A more detailed description of ACLs and ACEs can be found below.

System access control list (SACL)

The SACL specifies which attempts to access the object are audited in the security event log. The ability to get or set (read or write) any object's SACL is controlled by the privilege (user right, see below) SeSecurityPrivilege, which typically is only held by the local group Administrators.

An SD's Control Information

The control information of an SD contains various bit flags, of which the two most imporant bits specify whether the DACL respectively SACL are protected. If an ACL is protected, it does not inherit permissions from its parent.

What is an access control list (ACL)

As mentioned earlier, an ACL contains a list of access control entries (ACEs). The maximum number of ACEs is not limited, but the size of the ACL is: it must not be larger than 64 KB. This may not seem much, but should in practice be more that sufficient. Should you ever come in a situation where those 64 KB are not enough, I suggest you review your security concept from the very beginning.

What is an access control entry (ACE)

ACEs come in three flavors:

• Access allowed ACE
• Access denied ACE
• System audit ACE

All three variants are similar and contain the following information:

• SID of a Trustee to whom the ACE applies
• Access mask: the permissions to grant/deny/audit
• Inheritance flags: how to propagate the ACE's settings down the tree

Each ACE constitutes a "rule" which defines how the system is supposed to react when an attempt is made to access the object. Each rule (ACE) applies to exactly one trustee. The type of access that is covered by the rule is specified in the access mask.