Note that absolutely none of this is authoritative or directly based on relevant documentation. It’s mostly what I found and figured out and guessed and (in some cases) made up. Some of it may be wrong or dangerous or lead to disaster or confusion. I am not taking responsibility here for anything, not even spelling. Read and digest at your own peril!

So far we have encountered four things that have security descriptors and hence access control lists: services (and the Service Control Manager), network shares, scheduled tasks, and processes.

Of course, there are many more and the most commonly known securable objects are files and directories.

(Look out for registry keys next!)

The problem with ACLs is usually that there is no obvious way to edit them properly. For files and directories, Windows Explorer can do it. For registry keys, the Registry Editor can do it. And this is where GUI access ends (until we come to DCOM classes…). There are CLI tools to edit ACLs on services (sc.exe) and files and directories (icacls.exe) but for ACLs on processes and scheduled tasks there is no CLI tool available (that I know) in Windows.

PowerShell’s *-Acl cmdlets can (allegedly) edit ACLs of files and directories and registry keys but unfortunately this will not always work as .NET is apparently unable to edit ACLs of objects when a user has access to the ACL but does not have access to the object. (The CLI tools, GUI tools and C APIs do not have this issue!)

ACLs of files and directories are not regarded as very mysterious although there are a few oddities not known to everyone.

For example, the order of the ACEs or access control entries (or “elements”, I never know if the “e” stands for “entry” or “element”) matters. When a program accesses an object, it tells the system what type of access it wants and the first entry in the ACL that has something to say about that type of access will decide. I

Example: the ACL of a typical system file.

PS C:\Windows\System32> icacls cmd.exe
cmd.exe NT SERVICE\TrustedInstaller:(F)
        BUILTIN\Administrators:(RX)
        NT AUTHORITY\SYSTEM:(RX)
        BUILTIN\Users:(RX)
        APPLICATION PACKAGE AUTHORITY\ALL APPLICATION PACKAGES:(RX)
        APPLICATION PACKAGE AUTHORITY\ALL RESTRICTED APPLICATION PACKAGES:(RX)

Successfully processed 1 files; Failed processing 0 files
PS C:\Windows\System32>

The sddl (security descriptor definition language) is this:

PS C:\Windows\System32> (Get-Acl .\cmd.exe).sddl
O:S-1-5-80-956008885-3418522649-1831038044-1853292631-2271478464G:S-1-5-80-956008885-3418522649-1831038044-1853292631-2271478464D:P(A;;0x1200a9;;;SY)(A;;0x1200a9;;;BA)(A;;0x1200a9;;;BU)(A;;FA;;;S-1-5-80-956008885-3418522649-1831038044-1853292631-2271478464)(A;;0x1200a9;;;AC)(A;;0x1200a9;;;S-1-15-2-2)
PS C:\Windows\System32>

And translated:

O:S-1-5-80-956008885-3418522649-1831038044-1853292631-2271478464 The owner of this file turns out to be TrustedInstaller
G:S-1-5-80-956008885-3418522649-1831038044-1853292631-2271478464 The group of this file is also TrustedInstaller
D:P DACL begins and is protected (I think)
(A;;0x1200a9;;;SY) SYSTEM has certain access rights 0x1200a9
(A;;0x1200a9;;;BA) BUILTIN\Administrators has the same access rights
(A;;0x1200a9;;;BU) BUILTIN\Users has the same access rights
(A;;FA;;;S-1-5-80-956008885-3418522649-1831038044-1853292631-2271478464) TrustedInstaller has full access rights
(A;;0x1200a9;;;AC) ALL APPLICATION PACKAGES has the same access rights as SY, BA, and BU
(A;;0x1200a9;;;S-1-15-2-2) S-1-15-2-2 (turns out is ALL RESTRICTED APPLICATION PACKAGES) has the same access rights too

A “protected” DACL is a DACL that is not subject to inheritance applied after the DACL has been protected, i.e. it will not inherit from its parent. (The parent of a file or directory is the directory in which the file or directory is located.)

The access mask, given as either a number (here 0x1200a9) or as a combination of characters that act as a shortcut (here FA), is easily decoded.

MSFT describe access masks here: Access Rights and Access Masks.

In “short”, an access mask has 32 bits split into these categories:

31-24 23-16 15-0
More stuff Standard stuff Object-specific stuff

This major technical categories can be further split up:

Bit Value File access Directory access Sddl
0 0x1 Read data from file List files and subdirectories CC
1 0x2 Write data (and delete file) Add file DC
2 0x4 Append data Add subdirectory LC
3 0x8 Read extended attributes Read extended attributes SW
4 0x10 Write extended attributes Write extended attributes RP
5 0x20 Execute file Traverse directory WP
6 0x40 - Delete file or subdirectory DT
7 0x80 Read attributes Read attributes LO
8 0x100 Write attributes Write attributes CR
9-15 Various No idea    

This can be found in winnt.h in the Windows software development kit.

Standard access rights:

Bit Value Access Sddl
16 0x10000 Delete SD
17 0x20000 Read, write, and execute RC
18 0x40000 Write DACL WD
19 0x80000 Write owner WO
20-23 Various No idea  

It is perhaps a bit surprising that those bits don’t do much on their own. They have to be set in weird combinations.

Instead the required access is “bundled” in the generic access rights.

The only important bits for file and directory access are bits 28 to 31 in the generic section:

Bit Value Access Sddl
24 0x100000 SACL access (ignore)  
25-27 Various Reserved  
28 0x10000000 Full access FA
29 0x20000000 Execute FX
30 0x40000000 Write access FW
31 0x80000000 Read access FR

Note that Execute access means the ability to traverse a directory.

Also note that since pretty much every user has SeChangeNotifyPrivilege every user can already traverse (but not list) every directory.

So what does access mask 0x1200a9 mean?

The bit mask 0010 1110 1110 1001 gives us the following:

15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
    x   x x x   x x x   x     x
Bit Access
0 Read data
3 Read extended attributes
5 Execute
6 Delete file or subdirectory
7 Read attributes
9 No idea
10 No idea
11 No idea
13 No idea

The apparent result is that the file can be read and executed. (Bit 6 affects only directories.)

Same for a system directory C:\Windows\System32\:

PS C:\windows\system32> (Get-Acl .).Sddl
O:S-1-5-80-956008885-3418522649-1831038044-1853292631-2271478464G:S-1-5-80-956008885-3418522649-1831038044-1853292631-2271478464D:PAI(A;OICIIO;GA;;;CO)(A;OICIIO;GA;;;SY)(A;;0x1301bf;;;SY)(A;OICIIO;GA;;;BA)(A;;0x1301bf;;;BA)(A;OICIIO;GXGR;;;BU)(A;;0x1200a9;;;BU)(A;CIIO;GA;;;S-1-5-80-956008885-3418522649-1831038044-1853292631-2271478464)(A;;FA;;;S-1-5-80-956008885-3418522649-1831038044-1853292631-2271478464)(A;;0x1200a9;;;AC)(A;OICIIO;GXGR;;;AC)(A;;0x1200a9;;;S-1-15-2-2)(A;OICIIO;GXGR;;;S-1-15-2-2)
PS C:\windows\system32>
O:S-1-5-80-956008885-3418522649-1831038044-1853292631-2271478464 Owner is TrustedInstaller
G:S-1-5-80-956008885-3418522649-1831038044-1853292631-2271478464 Group is TrustedInstaller
D:PAI DACL begins
(A;OICIIO;GA;;;CO) Allow entry, inherited in specific ways, GA is the same as FA, full access, CO is creator owner, a placeholder for the object’s owner
(A;OICIIO;GA;;;SY) Same for SYSTEM
(A;;0x1301bf;;;SY) 0x1301bf for SYSTEM, I am not going to decode it
(A;OICIIO;GA;;;BA) Full access for BUILTIN\Administrators
(A;;0x1301bf;;;BA) 0x1301bf for BUILTIN\Administrators
(A;OICIIO;GXGR;;;BU) I am sure this means execute and read (same as FX and FR) for BULTIN\Users
(A;;0x1200a9;;;BU) And some 0x1200a9 for BUILTIN\Users
(A;CIIO;GA;;;S-1-5-80-956008885-3418522649-1831038044-1853292631-2271478464) Now they are just trying to drive me nuts…
(A;;FA;;;S-1-5-80-956008885-3418522649-1831038044-1853292631-2271478464) Full access for TrustedInstaller
(A;;0x1200a9;;;AC) And some 0x1200a9 for ALL APPLICATION PACKAGES
(A;OICIIO;GXGR;;;AC) Generic execute and read for ALL APPLICATION PACKAGES
(A;;0x1200a9;;;S-1-15-2-2) 0x1200a9 for ALL RESTRICTED APPLICATION PACKAGES
(A;OICIIO;GXGR;;;S-1-15-2-2) And generic execute and read for ALL RESTRICTED APPLICATION PACKAGES

Having clarified that, it is perhaps important to point out again that order matters.

If a Deny entry comes before an Allow entry, it will stop the Allow entry.

And if an Allow entry comes before a Deny entry, it will stop the Deny entry.

In this example, a Deny entry exists for BA before an Allow entry:

PS C:\Temp> icacls file
file BUILTIN\Administrators:(N)
     BUILTIN\Administrators:(F)

Successfully processed 1 files; Failed processing 0 files
PS C:\Temp> (Get-Acl file).Sddl
O:BAG:S-1-5-21-344341352-2539047333-2300305637-513D:PAI(D;;FA;;;BA)(A;;FA;;;BA)
PS C:\Temp> echo foo > file
out-file : Access to the path 'C:\Temp\file' is denied.
At line:1 char:1
+ echo foo > file
+ ~~~~~~~~~~~~~~~
    + CategoryInfo          : OpenError: (:) [Out-File], UnauthorizedAccessException
    + FullyQualifiedErrorId : FileOpenFailure,Microsoft.PowerShell.Commands.OutFileCommand

PS C:\Temp>

The Deny entry comes before the Allow entry and is seen first, hence the attempt to write to the file fails.

In this example, an Allow entry exists for BA before a Deny entry:

PS C:\Temp> icacls file
file BUILTIN\Administrators:(F)
     BUILTIN\Administrators:(N)

Successfully processed 1 files; Failed processing 0 files
PS C:\Temp> (Get-Acl file).Sddl
O:BAG:S-1-5-21-344341352-2539047333-2300305637-513D:PAI(A;;FA;;;BA)(D;;FA;;;BA)
PS C:\Temp> echo foo > file
PS C:\Temp> cat file
foo
PS C:\Temp>

Now the attempt to write to the file succeeds.

The next article describes how these ACLs can be ignored by a backup program.

Overview of securable objects

Object type Blog post API to set permissions Command to set permissions PowerShell cmdlet to set permissions
Service Services SetNamedSecurityInfo() sc.exe Set-Service
Network share Shares SetNamedSecurityInfo() net.exe Set-SmbShare
Scheduled task Scheduled Tasks (None, stored in registry) (None) (None)
Process Processes SetSecurityInfo() (None) (None)
File Files and Directories SetNamedSecurityInfo() icacls.exe Set-Acl
Registry key (None yet) SetNamedSecurityInfo() (None) Set-Acl

Next: Backup Operators