When a new version of Windows is released, Microsoft makes small enhancements to Access Control List (ACL) handling. The improvements often involve fundamental changes to the way permissions work, so it’s important to understand the impact on security. An ACL is the roll of permissions—such as Administrators - Full Control, Users – Read—assigned to a registry key, NTFS folder, or similar object. Each entry in an ACL, such as Users – Read, is known as an Access Control Entry (ACE).
In this article we’ll look at the modifications to ACL handling in Vista and Windows Server 2008 and how you can take advantage of them to improve security and simplify security management.
Owner Rights
One of the most important changes in Vista and Windows Server 2008 is the addition of a new SID called OWNER RIGHTS. In the new operating systems, if you're the designated owner of an object any effective permissions that apply to you on the object take precedence over ownership. If you have ownership of a folder but not write permission, you won’t be able to copy a file to that folder. UAC will not elevate permissions. You’ll need to modify the ACL on the folder, which you can do as the owner of the object, unless owner rights have been modified from the default.
The OWNER RIGHTS SID allows you to change this behaviour. Consider a scenario where you have ownership of a folder, but only READ permission on the ACL. If you add an ACE where the OWNER RIGHTS SID has WRITE permission (Figure 1), you’ll be able to copy a new file to the folder. If you now try to change the folder’s ACL, you’ll find that you no longer have access to alter it, because setting WRITE permission for the OWNER RIGHTS SID doesn’t allow the ACL to be modified. If you had specified FULL CONTROL instead of WRITE, you would have been able to copy a file and change the folder’s permissions. Fortunately, if you change the owner of an object, OWNER RIGHTS are not automatically transferred to the new owner. Therefore, if you lock yourself out of being able to modify permissions, the owner can be changed to resolve any permission-related issues. The OWNER RIGHTS ACE will remain, but inheritance will be set to Nothing, effectively disabling any permissions specified therein.
The OWNER RIGHTS SID in Vista and Windows Server 2008 allows administrators to assign ownership to a user or group, but provides a mechanism by which that user or group can be prevented from changing permissions on the object. The OWNER RIGHTS SID can be useful for simplifying rights assignment if you want to allow a user or group to create new files and folders, but not change permissions on them, by adding an ACE for OWNER RIGHTS as appropriate.
If a user creates an object and is subsequently removed from a group that is used to assign permissions to that object, the user is still the object’s owner. This gives them the ability to edit the object’s ACL and add an ACE for their user account, in order to regain access to the object. However, if you set DENY permission for WRITE_DAC (Change permissions) on subfolders and files as shown in Figure 2, when a user is removed from a group that is used to assign permissions to object(s), the user won’t be able to regain access to objects created by modifying the ACLs. Consider the ACL for a folder called Accounts:
OWNER RIGHTS:(OI)(CI)(IO)(DENY)(special access:)
WRITE_DAC
NT AUTHORITY\SYSTEM:(OI)(CI)F
FILESERVER\Accounts:(OI)(CI)C
BUILTIN\Administrators:(OI)(CI)F
My user account is a member of the group FILESERVER\Accounts only, and I create a new folder called Confidential Spreadsheets in the Accounts folder. I am by default the owner of this new folder. I am then removed from the group Accounts but remain the owner of the Confidential Spreadsheets folder. In Vista, as owner of Confidential Spreadsheets I have no standard access rights to that folder, such as READ and WRITE. Due to the WRITE_DAC DENY flag for OWNER RIGHTS, I am not able to modify the ACL and grant myself access.
The standard CREATOR OWNER permissions in XP, Windows Server 2003, and Windows Server 2008 give the owner of new objects FULL CONTROL to those objects only, by adding an ACE containing the object owner’s SID. In Windows XP and Windows Server 2003, whether or not the CREATOR OWNER ACE is removed, the net result would have been the same as in the situation described above; I would have been denied access to Confidential Spreadsheets.
If the ACL had been more complex and included an NT AUTHORITY\Authenticated Users:(CI)R ACE (List Folder Contents), I would have been able to browse the folder. In this situation, if my user account had been removed from the Accounts group and a WRITE_DAC DENY flag had not been set in an ACE for OWNER RIGHTS on an object I previously created, either I would be able to get direct access to the Confidential Spreadsheets folder because the CREATOR OWNER ACE granted FULL CONTROL to my user account, or I could modify the ACL because I’m still owner of the object. See a visual outline of the scenarios described above in Figure 3 and Figure 4. The bold text shows the differences in setup and outcome between the two scenarios. In real life, it’s unlikely that Authenticated Users would have any permission on a folder where sensitive data is stored. However, configuring an OWNER RIGHTS ACE can help to avoid security breaches in situations where ACLs have been misconfigured, providing an additional layer of defence.
If you add an ACE for OWNER RIGHTS on the Accounts folder at the time of creating the folder, and later decide to change the owner from your user account to the Administrators group for example, you’ll need to reset the OWNER RIGHTS ACE. Figure 5 shows how Windows sets the inheritance for the ACE to Nothing after the owner has been changed. Click the drop-down menu and reset the inheritance to Subfolders and files only as shown in Figure 2.
Default ACLs
The following tables show ACLs for the root of the system drive (usually C:\) and Windows (C:\Windows) directory, in Windows XP, Vista, Server 2003 and 2008. The table data was created using cacls.exe, which has been superseded by icacls in Vista. Because icacls has a slightly different output, to avoid confusion cacls has been used to generate the table data for all operating systems. The output of these commands can be a little confusing if you’ve never used them before (Table 1), so you might like to compare the tables with the GUI in Figure 6 and Figure 7.
The root directory of the system drive (C:\)
BUILTIN\Administrators and SYSTEM permissions have been divided into two ACEs. The Everyone and CREATOR OWNER ACEs have gone. BUILTIN\Users’ ACEs are replaced by Authenticated Users, with the exception of the BUILTIN\Users:(OI)(CI)R ACE, which cancels out the effect of removing Everyone.
The main difference is the absence of CREATOR OWNER. In Vista, when a user creates a folder in the root of the system drive, the user is not assigned any specific permission. Authenticated Users are assigned MODIFY permission. CREATOR OWNER remains in Windows Server 2008 as shown in Table 2 (see also Figure 8 and Figure 9.
The Windows directory (C:\Windows)
Permissions on the Windows directory have changed a little (Table 3). Power Users are gone and TrustedInstaller is in. ACEs for SYSTEM and BUILTIN\Administrators have been modified slightly, specifying different permissions: MODIFY for the top-level Windows directory and FULL CONTROL for subfolders and files. Hence, if you view these permissions using Vista’s GUI, you’ll see two entries for BUILTIN\Administrators and SYSTEM respectively (Figure 10 and Figure 11).
In Windows XP, Operating System (OS) files in the Windows directory were assigned Full Control for the Administrators group by default. That’s changed, and now a new SID called TrustedInstaller has full control and ownership of OS files (Table 4). This change is designed to prevent an application installer from automatically replacing OS files when run with administrator credentials (see also Figure 12 and Figure 13).
Junction Points have been added to Vista for the purposes of backwards compatibility. The Documents and Settings Junction Point, has an ACE of Deny for the Everyone group applied. This is to stop users from directly accessing or deleting the Junction Point. The Everyone group does however have the Bypass Traverse Checking right assigned to such Junction Points. This allows legacy programs to access files by specifying the full path for the file, but prevents casual users from browsing.
UAC behaviour and ACLs
When you browse to a folder that you do not have permission to read, UAC presents you with a dialog: You don’t currently have permission to access this folder – Click Continue to get access to this folder. What the dialog doesn’t make clear is exactly how you'll be granted access. When UAC grants access to a file or folder, unlike other UAC operations Windows Explorer isn’t restarted with an elevated token that grants temporary read access to the folder. Instead, a permanent READ ACE is created on the object, which in turn is inherited by all child objects. You might notice a short delay when you click Continue. This is because the new ACE is being added to the objects in the folder’s hierarchy. So don’t be surprised if after such an operation, a limited user has read access to part of the file system which they previously did not.
When writing to a folder for which you don’t have the necessary permissions, the behaviour is different. Try copying a file to a folder for which you don’t have write permission, and you’ll be presented with a similar UAC dialog: You’ll need to provide administrator permission to copy to this folder. The file will be copied, but only read access will be granted to the copied file.
