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.