One of the most important components of ACL-based security (WhatIsACLBasedSecurity) in Windows is unfortunately also one of the most subtle and overlooked: ownership. Discretionary access control is all about ownership. If I create an object, I become its owner, and ownership conveys certain inalienable rights: the right to read and change the object’s access control policy. A car, for example, has a very simple access control policy: It's either locked or it's not. When the car is locked, it denies access to everyone, regardless of who they are. When the car is unlocked, it allows access to everyone. As the owner of the car, you hold the keys that allow you to change the car's access control policy. You're always allowed to do this. Of course, you can give your keys to someone else, but then you've given ownership away.

Windows carefully tracks who owns each kernel object, each file, each service, and so forth. Any object that implements discretionary access control in Windows has a security descriptor associated with it (WhatIsASecurityDescriptor), and two important parts of that descriptor are the owner SID and the DACL (WhatIsAnAccessControlList). The owner and DACL are tightly related, as I described in WhatIsDiscretionaryAccessControl.

A funny thing about the owner SID is that it can be a user or a group. The latter is a special case that occurs only with the local Administrators group. Microsoft likes to simplify administration by removing as many barriers as posssible from system administrators. In this spirit, the operating system has traditionally set the default owner SID for administrators to be the Administrators local group, which means that, if Alice is an administrator on her machine, when she creates objects the owner SID won't be Alice personally but rather the Administrators group. If the machine in question is used only by administrators, for example, it's highly unlikely that anyone ultimately will be denied access to anything because they all share ownership. It's as if they all have copies of those car keys I was talking about earlier. The owner SID won’t be set to a group for a normal user though, and in modern versions of Windows workstation products, it may not even be set this way for an administrator.¹ Figure 41.1 shows an example of this special case behavior. One file was created by a normal user, the other by an administrator. Oh, and if you're not sure how to find these dialogs, just bring up the security properties for a file, press the Advanced button, and select the Owner tab.

Figure 41.1 Who owns these files, anyway?

Sadly, because most developers run as administrators (WhatIsANonPrivilegedUser), they never have to deal with this notion of ownership and thus they never really learn about it. This is yet another reason to develop code as a non-admin (HowToDevelopCodeAsANonAdmin), because you'll start to see firsthand how Windows security works. Okay, I'll get off my soapbox now.

Technically, as the owner of an object, Windows implicitly grants you two permissions (WhatIsAPermission):

• READ_CONTROL ("Read Permissions")

• WRITE_DAC ("Change Permissions")

So, if you're the owner of an object, you’re always allowed to open it for one or both of these permissions, regardless of what the DACL says! It's like walking up to your car with its doors locked. The DACL on the car says everyone is denied access, but that doesn't keep you out. Using your keys, you can change that DACL to allow everyone in, then hop in the car. Once inside, you can change the access control policy again if that helps make you feel any safer.²

There's a very important permission that you should know about because it impacts ownership in a big way. Its friendly name is "Take Ownership," and the programmatic name for it is WRITE_OWNER. This is a permission that you can grant to anyone via an object's DACL, and it’s specifically designed to be used to transfer ownership from one user to another. Here's a very typical example that shows how it works. The administrator of a system, say Alice, has created a file for some user, say Bob. She's gone to all the work of initializing the file and putting it in the right place, and now she wants to hand ownership off to Bob. So she edits the DACL on the file, granting Bob the "Take Ownership" permission. Bob can now bring up the security properties for the file, hit the Advanced button, select the Owner tab (as shown in Figure 41.1), and change the owner of the file by selecting his name from the "Change owner to" list box and pressing Apply. Now that he's the owner, he can change the DACL however he likes. Note that the actual change of ownership was instigated by the new owner. I know of no way in Windows to assign ownership directly to someone.

It may come as a surprise that when you grant someone "Full Control" over an object, you're also granting permission for a transfer of ownership! As a practical example, take a look at Figure 41.2 and note the subtle difference between the two permission grants I've given to Alice.

Figure 41.2 Forfeiting ownership accidentally?

In the right screen, I granted Alice permission to read and modify the file, but I didn’t grant "Full Control." What's so subtle about this is that, if you look in the "Advanced," dialog that enumerates the granted permissions (Figure 41.3), you'll see what "Full Control" really means. These dialogs show the permissions actually granted based on the settings in Figure 41.2. Granting "Full Control" is subtly different from just granting Read and Modify permissions: It also allows the user to change the DACL and take ownership of the object. So be wary about giving out "Full Control." It's bad enough to allow someone less trusted to change the DACL of your object, but taking it away from you permanently via an ownership transfer is even worse.

Figure 41.3 Subtle difference between Read and Modify and Full Control

There's one last thing to say about ownership. Windows has a privilege (WhatIsAPrivilege) that allows its holder to wrest ownership away from someone without their knowledge or consent. It's called SeTakeOwnershipPrivilege, and if it's been granted to you and you've enabled it (HowToUseAPrivilege), you can open up any object in the system for WRITE_OWNER permission, which means that you can transfer ownership to yourself. Needless to say, this is a very useful tool in the hands of a trusted administrator but a terribly dangerous one in the hands of a bad guy. By default it's granted to the Administrators local group. See HowToTakeOwnershipOfAnObject to learn how to use this privilege.

¹ As of Windows XP, this behavior can be controlled via security policy (see the security option entitled "System objects: Default owner for objects created by members of the Administrators group"). On Windows XP, the default policy has changed: Administrators have personal ownership of objects they create, just as normal users do. On Windows Server 2003, the default policy is what it has always been: Administrators are treated specially, and they share ownership of objects by default.

² Note that I'm conveniently ignoring the special case that anyone inside the vehicle can change its access control policy. Also note that there's a race here (a bad guy can jump in the car before I get the door locked again). It's not a perfect analogy, but I hope it helps.

Ported by KennyKerr