Deleting from the WinSxS directory

  • Article

In Windows Vista, the directory %windir%\WinSxS has much stronger protection on it than it did in Windows XP and Server 2003.  The owner/group is now a SID named "Trusted Installer", a service SID used to start the TrustedInstaller service.  Users other than the trusted installer are granted only generic-read/generic-execute by default.  This increased protection ensures that only the trusted installer service is allowed to modify the servicing-related metadata and files.  If a limited user could modify a file in the directory, for example, they could convince the servicing stack to overwrite one binary with another when the next administrator comes along to enable the Games for Windows package.

Content is added to this directory in response to installing applications, enabling packages in the add-remove-programs UI, and installing Windows Out-of-Band releases.  Content is removed from this directory as a result of uninstall + scavenging - a topic for another time.  One important note - uninstalling your application or Windows app will not necessarily remove the physical bits from the system.  The servicing stack marks the bits as unusable and prevents their use through "normal" means.  Files and directories will be removed over time as the servicing system cleans up after itself.  Administrators should not, for any reason, take it upon themselves to clean out the directory - doing so may prevent Windows Update and MSI from functioning properly afterwards.  Preventing accidental deletion from the directory is accomplished by putting a strong security descriptor on the directory that inherits to its children.

The directory itself is marked with the SDDL:

  • O:S-1-5-80-956008885-3418522649-1831038044-1853292631-2271478464
  • G:S-1-5-80-956008885-3418522649-1831038044-1853292631-2271478464
  • D:PAI
    • (A;OICI;FA;;;S-1-5-80-956008885-3418522649-1831038044-1853292631-2271478464)
    • (A;OICI;0x1200a9;;;BA)
    • (A;OICI;0x1200a9;;;SY)
    • (A;OICI;0x1200a9;;;BU)"

That long SID (S-1-5-80-956008885-3418522649-1831038044-1853292631-2271478464) is the service sid for Trusted Installer.  By parts, that SDDL means "the owner and group are Trusted Installer; there is a protected and auto-inherit DACL; the ACEs of that DACL grant the trusted installer full access; the ACEs of the DACL also grant builtin-administrators, local system, and builtin users generic-read and generic-write access; each ACE is also automatically inherited by child containers and child objects."

So, the security descriptor on the object will prevent even administrators from creating or deleting objects underneath %windir%\winsxs, which is why even an elevated administrator cannot (by default) delete content.

Elevated administrators do have (by default) the SeTakeOwnership privilege enabled.  Such a token could take ownership of anything under %windir%\winsxs.  Once the owner, the administrator could then reset the SDDL on the object, granting themselves full access to the object.  Of course, the generic LUA administrator token does not allow enabling the "take ownership" privilege, so this is only possible after answering the LUA elevation prompt successfully.

I leave it to the intrepid user to figure out the correct combination of "takeown.exe", "icacls.exe", and "rmdir" to actually remove content.