Owner SID Changes

In Windows, an object owner has full control of the object; even if the owner is denied access to the object, she can still access it because an object’s owner implicitly has the READ_CONTROL and WRITE_DAC rights. WRITE_DAC is a powerful right that can be used to change the object’s access control policy. In Windows Vista, this is still true. However, a developer can change the owner semantics by adding an Owner Rights ACE to an object’s discretionary access control list (DACL) with an access mask that defines what the owner can do.

The Owner Rights SID is new in Windows Vista; the SID is S-1-3-4, and the SDDL constant is SDDL_OWNER_RIGHTS (“OW”). It can also be simply declared with:

 SID OwnerRightsSid = {            SID_REVISION, 1,            SECURITY_CREATOR_SID_AUTHORITY,            SECURITY_CREATOR_OWNER_RIGHTS_RID };

If you’re sure that your code will only run on Windows XP and later, a more robust and nearly as efficient way to accomplish the same thing is to use CreateWellKnownSid with an argument of WinCreatorOwnerRightsSid.

When the DACL for the securable object is evaluated during an access operation in Windows Vista, a check is made for ACEs containing the Owner SID to determine the rights granted to the object’s owner. If the DACL contains no Owner SIDs, the object’s owner is granted the READ_CONTROL and WRITE_DAC rights, as in previous versions of Windows. However, if the DACL contains one or more Owner ACEs, the access check will use those entries to determine the owner's rights.

For some customers, this is a very useful feature. For example, an administrator can ensure that users who create files and folders will not change the intended access control policy on those resources or that users are unable to change settings on an object they created after they have been removed from a particular group.

Another example is related to the ability for services to be assigned a service SID in Windows Vista, as we covered in Chapter 5. Some resource isolation can be achieved by ACL’ing objects with a service's SID, but not resources created by the service at run time: they will be owned by LocalSystem, NetworkService, or LocalService, and hence will be ultimately modifiable by other instances of such services. By adding an Owner ACE to the ACLs of those resources, we can prevent other services from accessing resources belonging to our service, because the other service can’t change the access controls.

As a final example, an Active Directory administrator can allow users in a specific group to create objects under an Organizational Unit (OU) but can then restrict their ability to modify or create group objects when removed from that group. This change allows the emulation of a standard UNIX access control trick: a user can create a file and then not be able to access it once it has been closed. This happens because the handle returned from CreateFile allows all access (except WRITE_DAC when the inherited ACL from the containing folder contains OWNER ACEs that deny WRITE_DAC), so the program can do whatever it needs to create the file. The inherited ACL can be set to have an OWNER ACE that does not contain WRITE_DAC and whatever other rights that it decided not to grant once the file is closed. However, if the user could write code that directly sets an ACL at the time the file is created, it need not inherit anything from the parent, so this measure isn’t completely foolproof. This issue could also apply to Active Directory objects.

Such a change does not affect TakeOwnership semantics–a user with SeTakeOwnership privilege will still be able to take ownership and acquire READ_CONTROL and WRITE_DAC rights. When an administrator takes ownership of a file (which changes the owner SID), then the DACL is examined for ACEs that contain the Owner SID. If an allow-Owner ACE is found, then READ_CONTROL | WRITE_DAC are added to the access mask. If a deny-Owner ACE is found, then READ_CONTROL | WRITE_DAC are removed from the mask.

Finally, this change does not affect quota either. Quota is charged to the owner of an object, even if that owner does not have WRITE_DAC rights.