Taking ownership of an object is easy when the operating system provides an interactive security editor. For example, to take ownership of a file all you need to do is bring up the security properties for it and press the Advanced button (as shown in WhatIsAnAccessControlList). Then click the Owner tab and you'll see a property page that looks like Figure 46.1.

Figure 46.1 Getting ready to take ownership of a file

This user interface is pretty smart. Not only does it show you who currently owns the file, but, if you have permission to take ownership of the file either because you've been granted WRITE_OWNER permission to it or because you've been granted SeTakeOwnershipPrivilege on the machine (WhatIsOwnership), this dialog tells you which accounts you may assign as the files new owner. Note that we're talking about "taking" ownership here, not assigning it, so normally the only account in this list is the user account under which you're logged in. However, there's one special case: If you're a member of the Administrators local group, you'll see that account listed along with your user account. This is only case where a group is allowed to act as an owner, as I discussed in WhatIsOwnership. I was running under the built-in Administrator account when I took the screenshot in Figure 46.1, which is why you see those two accounts in the list box. If wanted to take ownership at this point, I would just select one of the accounts in the list box and hit OK. Be careful not to do this accidentally if all you want to do is view the owner! If you’re working with an object that has children (like a folder or registry key), you’ll also see a checkbox that allows a recursive change as well.

Although there are many different types of secure object, it turns out that very few of them sport an interactive security editor like the one shown in Figure 46.1. Think about a process, for example. It has an owner, a DACL, and a SACL, just like a file. But administrators don't normally bother modifying the security settings for individual processes because they're transient, so there's no built-in user interface for doing this. Windows services don't have a GUI for editing their security settings to control who is allowed to start and stop the service, or for auditing these actions. As of this writing, if you want to set the DACL on a service you need to either buy a third party tool that does this or write some code to do it yourself.¹ Why am I talking about DACLs in an item that's dedicated to taking ownership? Because the only time you ever need to forceably take ownership is when the DACL doesn't grant you WRITE_OWNER permission already. An extreme example is when you're completely locked out of an object—when its DACL doesn't grant you any permissions at all.

I remember back when I was first learning about Windows security, I accidentally locked myself out of a Windows service. I had written some code to set its DACL programmatically so I could control who was allowed to start and stop it. But I accidentally set an empty DACL on the service, and because I wasn't the owner (SYSTEM owns all services) there was nothing I could do short of getting some code running as SYSTEM and granting myself access again. At this point, all I wanted to do was to delete the darned thing. As there wasn't a GUI to change the owner, I resorted to writing the code to do it programmatically. It was a good exercise in that it really drove home what ownership means. Here are the steps I had to take:

1. Enable SeTakeOwnershipPrivilege in my process token (HowToUseAPrivilege).
2. Open the service object for WRITE_OWNER permission.
3. Change the owner SID to that of my user account.
4. Close and reopen the service for WRITE_DAC permission.
5. Change the DACL to grant myself access (HowToProgramACLs).
6. Close and reopen the service for DELETE permission.²
7. Delete the service.

In version 2.0 of the .NET Framework, taking ownership of an object programmatically is almost trivial. Here's an example that takes ownership of the Clipbook service:

 using System.Security.AccessControl;
 using System.Security.Principal;


 class App {
   static void Main() {
     string svcName = "clipsrv";
     // load the old owner into a security descriptor
     LeafObjectSecurity sd = LeafObjectSecurity.CreateFromName(
       ObjectType.Service, svcName, true, false);
     Console.WriteLine("Old owner: {0}", sd.Owner.AccountName);


     // change the owner to be the current user
     // (alternately you can set it to the local
     //  Administrators group if you're an admin)
     sd.Owner = SecurityIdentifier.CreateFromUserName(
       WindowsIdentity.GetCurrent().Name);


     // apply the new security descriptor to the service
     sd.Persist("clipsrv");
   }
 }

¹ You could use group policy (WhatIsGroupPolicy) to make broad changes throughout a domain or organizational unit, but there's no built-in tool to do this locally on the machine where the service resides.

² Remember, as the new owner of an object you're guaranteed only two permissions: READ_CONTROL and WRITE_DAC. See WhatIsAPermission if you’re not sure what these permissions mean.

PortedBy RjaeEaston