Security

New ACLs Improve Security in Windows Vista

Jesper Johansson

 

At a Glance:

  • What’s new in ACLs
  • Tighter controls on administrator
  • Trusted installer permissions
  • Modified users and groups

The fundamental structure of access control lists (ACLs) has not changed much for Windows Vista, but there are a number of small yet important changes you need to be aware of. Some changes

were necessary because in Windows® XP, ACLs played a part in several problems. First, most Windows XP users run as administrator. That is, they use an account that is a member of the built-in Administrators group. For home users, this is a virtual certainty because all accounts added during setup become administrators. Therefore any programs such users execute will also execute with administrative privileges, giving them unfettered access to the operating system. Of course, this is especially problematic if those programs are of the unsavory variety.

The second problem that needed to be addressed was that the default ACLs in earlier versions of Windows made many people nervous as they included ACL entries (ACEs) for Everyone, Power Users, and the like. For instance, the default ACL on the root of the boot volume (normally C:\) in Windows XP gave Read access to Everyone and granted permission to create folders for members of the Users group. Finally, in Windows XP there were limitations on what you could do with ACLs. For instance, there was no way in Windows XP to assign permissions to the current owner of an object. You could give the owner permissions but if the owner changed, those permissions were not transferred. Likewise, owners always had implicit rights to an object, no matter what permissions they were assigned on that object.

With Windows Vista™, Microsoft embarked on a project to resolve many of these issues, and to enable support for other features, such as User Account Control (UAC). This article focuses on the major changes related to access control in Windows Vista. Next month I’ll continue with a look at the tools you can use to manage access control.

New and Modified Users and Groups

Some users and groups in Windows Vista are new, and some old friends from Windows XP have been removed. Moreover, the way some of them work has been modified. Each of the changes has some impact on how you manage access control.

Administrator—Disabled By Default The built-in Administrator account, the one with a relative identifier (RID) of 500, is now disabled by default in most cases. Administrator was meant to be an emergency account, used for salvaging the computer when all else failed. Far more often, however, it ended up being used as the standard administrative account, thereby violating several principles of security. The most notable of these—accountability—means you lose ability to track who is making changes on your system. Therefore, the account was partially deprecated. Eventually, Microsoft may deprecate the account altogether, but for now it is disabled by default. If you have no other local accounts in the Administrators group, RID 500 is still usable in the recovery console and safe mode, but otherwise it cannot, and should not, be used.

Note that there is a difference between the built-in Administrator account and other accounts in the Administrators group. We typically capitalize "Administrator" when referring to the account with RID 500 to distinguish it from an "administrator," which is any other account that is a member of the built-in Administrators group. Group names are similarly capitalized.

In Windows XP, the built-in Administrator account had a number of special rights and privileges that no other administrator had. Many of these have been removed in Windows Vista, but there are two notable exceptions: First, a disabled Administrator account can be used in the recovery console if there are no other local administrators. Second, the Administrator is not subject to UAC and will always have a full administrative token. The same is true of the Domain Administrator (RID 500 on a domain).

Power Users Permissions Removed The old Power Users group has, for all practical purposes, been abolished. The group is still there, but most of the permissions granted to it have been removed. It was not exactly a secret that a user who was a member of Power Users was effectively an administrator who had simply not yet made himself an administrator. I once took over a machine that was fully patched, running Windows XP Service Pack 2 (SP2), in less than 45 minutes by granting myself administrative privileges. That included the reconnaissance, writing a small program in C++, and logging off and on again to complete the take-over—all enabled because I was a member of Power Users.

Many organizations have granted sophisticated permissions to the Power Users group and rely on their users being members of it, so it was not feasible to remove the group in Windows Vista. However, Microsoft is likely to completely remove Power Users in an upcoming version of Windows. You would be well advised to start planning to migrate away from Power Users.

Trusted Installer The Trusted Installer is actually a service, not a user, even though you see permissions granted to it all over the file system. Service hardening allows each service to be treated as a full-fledged security principal that can be assigned permissions just like any other user. For an overview of this feature, see the January 2007 issue of TechNet Magazine. The book Windows Vista Security (Grimes and Johansson, Wiley Press, 2007) explores service hardening in detail, including how it is leveraged by other features, such as the firewall and IPsec.

Service SIDs are not issued from the authorities we have seen before, such as NT AUTHORITY or a domain. The full name for the TrustedInstaller virtual account is NT SERVICE\TrustedInstaller and its SID is:

S-1-5-80-956008885-3418522649-1831038044-1853292631-2271478464

You can see the SID for any service, even for ones that do not exist, by running the sc showsid command, as shown in Figure 1.

Figure 1 sc showsid shows the SID for any service, including those that do not exist yet

Figure 1 sc showsid shows the SID for any service, including those that do not exist yet (Click the image for a larger view)

This SID begins with S-1-5-80. Notice that the first sub-authority here is 80, which stands for SECURITY_SERVICE_ID_BASE_RID, meaning this SID is issued by the NT SERVICE sub-authority to a service. The same is true for any service. The remaining sub-authorities and the RIDs are based on the service name itself. This enables a developer to grant permissions to his service without actually having to build and install the service first as the name is deterministic and will not vary from machine to machine.

In case you can’t find the TrustedInstaller service in the services manager, its display name is "Windows Modules Installer."

Help and Support Accounts Removed The Support_xxxxxx and HelpAssistant accounts are both removed on clean installations of Windows Vista, although they are retained when upgrading from a previous version of Windows. The Support_xxxxxx account was used to run scripts from the support center. Some OEMs who provided their own help content may also have provided their own support accounts. It is unclear what will happen to OEM accounts, but more than likely the OEMs will simply stop creating them. Strictly speaking, they are no longer necessary. In fact, from a security perspective, it was not a great idea to allow users to execute scripts from the help center as another user anyway, so it would be best if those accounts disappeared. Windows Vista has a new mechanism to accomplish this task.

The HelpAssistant account was used during remote assistance. As with the help center, the remote assistance feature has been re-engineered to avoid the need for the HelpAssistant account and consequently it has been removed.

New Network Location SIDs Windows NT®-based operating systems have always had some network location-based SIDs, such as NETWORK and INTERACTIVE, denoting users logging on from the network and interactively. There is also a REMOTE INTERACTIVE LOGON SID that is assigned to users logging on via Terminal Services. (Note that Terminal Services users will actually have both REMOTE INTERACTIVE LOGON and INTERACTIVE LOGON in their tokens.) In Windows Vista, two more are added: DIALUP and INTERNET. The exact rationale for adding an account denoting a logon via dial-up is a bit unclear, particularly when more and more users will not go online if the only network available is a phone line, but it is there now. INTERNET is obviously meant to indicate any user logged on from beyond the local area network. NETWORK, however, still designates any user logging on from the network, including the Internet.

OWNER RIGHTS and Owner Rights There is now a SID for OWNER RIGHTS, which applies to whoever happens to own a file at the time it is accessed. It is primarily used to restrict what the owner can do with the file. There are two notable changes to how owner rights work as compared to Windows XP. First, if you are the owner of the object, but there is an ACE on the object that applies to you, the rights in the ACE will supersede the fact that you are the owner. This is a major change and will significantly impact certain aspects of system administration as we are used to the owner having implicit rights. Second, the OWNER RIGHTS SID can be used to further restrict what the owner can do with an object.

Let’s assume we have a folder, owned by the user Jesper, with an ACL as shown in Figure 2. The user, Jesper, only has Read permission on the folder, even though he is the owner. If he tries to copy a file into it, the copy will fail because Jesper does not have permission to write to the folder. This is not entirely intuitive from the error messages, however. If you attempt to copy a file into a folder you own but don’t have write permissions for using Windows Explorer®, here is what happens: first, Explorer says you need to elevate permissions to copy the file and asks you to elevate, but the file copy fails because you do not have rights to copy anything into this folder. You get an error message that says "You need permission to perform this action" and a button each for "Try again" (as if that might help) and "Cancel". This is in spite of the fact that you are the owner.

Figure 2 Only Local System and one other user have access to this folder

Figure 2 Only Local System and one other user have access to this folder (Click the image for a larger view)

If Jesper tries to change the ACL on the file, he will get prompted to elevate his token to do so. Since he is the owner of the file, he can do this. The owner retains implicit rights to read and change the ACL (READ_CONTROL and WRITE_DAC) unless there is an ACE for OWNER RIGHTS that specifies otherwise.

To understand the effect of the OWNER RIGHTS SID, let’s add that to the ACL above. We now have the permissions shown in Figure 3.

Figure 3 Adding OWNER RIGHTS permissions to the folder changes Jesper’s permissions

Figure 3 Adding OWNER RIGHTS permissions to the folder changes Jesper’s permissions (Click the image for a larger view)

With these permissions, if the Jesper account attempts to copy something into the folder, this act is immediately successful because Jesper is the owner and has the appropriate rights. However, if Jesper tries to change the ACL on the object, that action will fail! The ACE for OWNER RIGHTS specifies that the owner shall have only Modify privilege, not the ability to modify the discretionary access control list (DACL). Thus, OWNER RIGHTS is used primarily to remove WRITE_DAC, the ability to modify the security descriptor, from the owner.

If an administrator changes the owner of the object, the OWNER RIGHTS permissions are not automatically transferred to the new owner. In this case the OWNER RIGHTS ACE is disabled by marking it as inherit-only but not applying it to either containers or objects—in other words, not applying it to anything at all. This is done to ensure that administrators do not get completely locked out of the object. To get the OWNER RIGHTS ACE to take effect again, the Administrator has to go in and manually re-enable the ACE. To do so, you mark it as applying to this folder, subfolders, and files, as desired.

There are several interesting scenarios in which the OWNER RIGHTS SID can be useful, such as when the administrator wants users to be able to create files and folders on a file server, but does not want them to be able to change ACLs on those folders. Another likely situation occurs when users were members of a group at some point and created some objects but, perhaps for business reasons, they were later removed from this group. At this point, they should not be able to modify the settings on those objects.

OWNER RIGHTS is used fairly extensively in service hardening. When a service creates a transient object at run time the creator of the object is the primary SID of the service process, typically LocalSystem, NetworkService, or LocalService, and not the SID for the service itself. That means that any other service running in the same process context can modify the object, which is almost certainly not desirable. By setting an OWNER RIGHTS SID on such objects, the OS can keep other services from accessing them.

Default ACLs

The default ACLs in Windows XP were actually reasonably good. Apart from some minor issues, such as permitting users to put files in the root of the boot volume, they were generally sensible. However, some OEMs apparently decided they knew better what constituted reasonable security. The screen in Figure 4 shows a picture of the ACL on the Windows directory on a computer running Windows XP Media Center Edition from a major OEM. The OEM essentially disabled file system security.

Figure 4 An OEM-configured ACL

Figure 4 An OEM-configured ACL

Microsoft did some tweaking to ACLs in Windows Vista. First, if you are accustomed to Windows XP, you know that all OS files are owned by the Administrators group and administrators have full control over those files. As a member of that group, you thus had unfettered access to those files. That’s not the case in Windows Vista.

Trusted Installer In Windows Vista, most of the OS files are owned by the TrustedInstaller SID, and only that SID has full control over them. This is part of the system integrity work that went into Windows Vista, and is meant specifically to prevent a process that is running as an administrator or Local System from automatically replacing the files. In order to delete an operating system file, you thus need to take ownership of the file and then add an ACE on it that lets you delete it. This provides a thin layer of protection against a process that is running as LocalSystem and has a System integrity label; a process that has lower integrity is not supposed to be able to elevate itself to change ownership. Some services, for instance, can run with medium integrity, even though they are running as Local System. Such services cannot replace system files so an exploit that takes over one of them can’t replace operating system files, making it a bit harder to install a rootkit or other malware on the system. It also becomes more difficult for system administrators who are offended by the mere presence of some system binary to remove that binary.

Deny ACEs You will find that many objects in the file system have Deny ACEs for Everyone, which has caused quite a bit of consternation for many administrators. If you turn on the "Show hidden files option," you’ll see the familiar Documents and Settings directory. But if you click on it, you will get an Access Denied error. To understand what is going on with Documents and Settings, look at the directory listing in Figure 5.

Figure 5 Documents and Settings is a junction point, not a directory

Figure 5 Documents and Settings is a junction point, not a directory (Click the image for a larger view)

Documents and Settings is, in fact, not a directory at all—it is a junction point! Recall that junction points are similar to symbolic links that simply redirect the access to somewhere else. In this case, the junction goes to a directory called C:\Users. Microsoft has actually modified the file system namespace significantly in Windows Vista, and the user data is now moved to C:\Users. Other elements beneath the old "C:\Documents and Settings\<Username>" namespace have also moved. For example, "C:\Documents and Settings\<Username>\Application Data" has moved to C:\Users\<username>\appdata\roaming. You can see the changes very clearly if you drop to a command line and use the dir /a command as I did in Figure 5. The reason the namespace has changed so drastically is to make it more intuitive to users and to get a cleaner separation between documents and data. Rather than storing all data files underneath the My Documents folder, developers can now create their own folders under the user’s profile, and the user will see them there. Application data for all users now goes into a hidden folder called %systemroot%\ProgramData instead of under Documents and Settings\All Users\Application Data.

Microsoft did not remove the "C:\Documents and Settings" namespace because older applications may be hardcoded to use that name rather than the preferred environment variables, such as %USERPROFILE%. Those applications would break if "C:\Documents and Settings" were to disappear. Instead, they are now represented as junction points or symlinks, for backward compatibility. Applications that hardcode those paths may still break, depending on how they access the data in them, but those applications are already broken on Windows versions in languages other than English. This is really key. When an update to Windows, such as Windows XP SP2 or Windows Vista, breaks third-party programs, it is almost always because the developers of those programs made invalid assumptions or used Windows in a way they were not supposed to.

If you try to open a file, for example, by typing "C:\Documents and Settings\<Username>\My Documents\foo.txt", it would work, assuming you have a file in that place called foo.txt. However, if you try to browse to "C:\Documents and Settings\<Username>\My Documents", you get the "Access Denied" error message. To understand what is happening, look at the ACL in Figure 6.

Figure 6 There is a deny ACE on Documents and Settings

Figure 6 There is a deny ACE on Documents and Settings (Click the image for a larger view)

Look at the first ACE in the list. It is a Deny ACE for Everyone to list the folder contents. Programs can traverse the junction points and open documents with absolute paths because Everyone has the Bypass Traverse Checking privilege (also known as SeChangeNotifyPrivilege). Attempts by a user or process to enumerate the directories they represent will fail because of the deny ACE. That is why you can’t actually see what is inside C:\Documents and Settings, nor can you delete the "directory." The main point of putting that Deny ACE there is to prevent users from deleting the junction and breaking older applications. It also serves to remind developers not to code applications to use the old namespace and instead to start using environment variables or registry strings to insulate application from any future changes and language differences.

Note that all these junction points are hidden by default, so the vast majority of users will never see them. To prevent those who do from deleting them, Microsoft put a Deny ACE in for "List Folder."

Bypass Traverse Checking The reason users can access files they have rights to inside folders (or junction points) they don’t have rights to is that everyone has the Bypass Traverse Checking privilege. Bypass Traverse Checking, or SeChangeNotifyPrivilege, is actually the most basic privilege in Windows and is granted to a process that has all other privileges removed unless the process specifically requests to have that privilege removed too. This is what happens when you launch a process using the runas /trustlevel:0x10000 < line in Windows Vista. The program specified in <command> will run with a restricted token and all privileges except SeChangeNotifyPrivilege are stripped from the process token.

As a point of interest, trustlevel 0x20000 gives you a token with the normal set of SIDs but stripped privileges. 0x40000 gives you a completely normal token.

Default Permissions

The default permissions on the file system in Windows Vista have changed a little from Windows XP. If you look at the ACL on %systemdrive% (normally the C: drive—the boot volume), on Windows XP or Windows Server® 2003, you see this (or something very similar on early versions of Windows XP):

D:AR
(A;OICI;FA;;;BA)
(A;OICIIO;FA;;;CO)
(A;;0x1200a9;;;WD)
(A;OICI;FA;;;SY)
(A;OICI;0x1200a9;;;BU)
(A;CI;0x100004;;;BU)
(A;CIIO;0x100002;;;BU) 

Here is the same ACL on the same directory on Windows Vista:

D:PAI
(A;;FA;;;BA)
(A;OICIIO;GA;;;BA)
(A;;FA;;;SY)
(A;OICIIO;GA;;;SY)
(A;OICI;0x1200a9;;;BU)
(A;OICIIO;SDGXGWGR;;;AU)
(A;;LC;;;AU) 

There are a number of differences worth noticing. First, there are now two ACEs for BA (BUILTIN\Administrators) instead of just one. However, the net effect is the same. In Windows Vista, one ACE is not inherited and grants full access to the root, and one ACE is an IO (Inherit-Only) ACE, inherited by containers and objects, and grants GA (Generic All, or full control). The same holds true in the replacement of the one ACE for SY (LocalSystem) with two in Windows Vista. In Windows XP, the single ACE granted full access and was inherited by objects and containers. Again, there is no net change here. The main reason why the ACL was changed was to clarify and break out the privileges so that the ACL is easier to manage, and even potentially to restore.

More interestingly, the ACE for CO (Creator/Owner) is gone. That means that if a user creates an object in the root of the file system, there are no special permissions accrued to the creator any longer.

You can also see that the ACE for WD (Everyone) has been removed. Many people who were interested in security, although they may not have completely understood the implications of their actions, were unduly concerned about that ACE. Microsoft tried in vain for years to explain that Everyone was functionally identical to built-in Users, but it appears they finally gave up and removed that ACE altogether. Since there is an identical ACE for BU (BUILTIN\Users) that is also inherited by both containers and objects, the net effect is that nothing has changed.

In addition, two of the ACEs for BU (built-in Users) have been replaced with ACEs for AU (Authenticated Users). The reason is that the Guest account is a member of built-in Users (by virtue of the fact that INTERACTIVE is a member of built-in Users), but Guest is not a member of Authenticated Users. To allow the Guest account to read and execute files, the 0x1200a9 (effectively Read and Execute) ACE remains granted to BU. However, the ACEs that grant permissions to create files and folders are granted to Authenticated Users instead. This is a departure from Windows XP. In Windows XP, a Guest could create files in the root. In Windows Vista, a Guest can’t create such files. Keep in mind, though, that this is all moot unless the Guest account is enabled and guests are somehow able to reach the root of the boot volume. By default, the Guest account is disabled.

Leaving the best for last, there are a couple of very interesting and seemingly troublesome ACEs in the two lists above. In Windows XP, you have an ACE inherited by containers, specifying 0x100004 for built-in Users. That ACE grants Users the right to create subfolders, and sub-subfolders, and so on, since it is inherited by containers. There’s also an inherit-only ACE, inherited by sub-folders for 0x100002. That ACE grants users the right to create files and subfolders in folders they create under the root. In other words, these two ACEs allow users, including Guests, to create files and folders under the root, as I mentioned before.

In Windows Vista, the corresponding ACEs are an inherit-only ACE, inherited by both containers and files, granting GR (Generic Read), GX (Generic Execute), and GW (Generic Write) along with SD (Read Security Descriptor), and an ACE that applies only to the root itself that grants LC privilege. LC is actually a short-cut term that belongs on ACEs in Active Directory®. In Active Directory it means that a user can list child objects. However, the hexadecimal value of LC is 0x4. For a directory, 0x4 means FILE_ ADD_SUBDIRECTORY, which becomes functionally equivalent to 0x100004, since we already have 0x100000 (the ability to use the object for synchronization) from the 0x1200a9 ACE. In other words, it provides exactly the same effect as in Windows XP—users can create subdirectories under the root.

Where are the hex values from? And, what are hex values in the first place? As you have noticed by now, access control is full of hexadecimal (base16) numbers, like 0x1200a9. These are actually bitmask representations of bits in an access mask that are set to "on," meaning that they are used in the particular ACE. When you use a tool, such as icacls, sc, or secedit to list an ACL, the bitmasks are represented by much friendlier text strings if there is a 1:1 match.

Therefore, to determine what LC means all you have to do is go to the MSDN® Web site, find the string LC and look in the Access right value column to find ADS_RIGHT_ACTRL_DS_LIST. If you then open up the Iads.h header file and look for that string, you will find that it corresponds to 0x4. For non-Active Directory strings (those not prefaced with "ADS_RIGHT"), you will generally find the hex value in AccCtrl.h instead. Once you have the hex value, it is an easy job to look it up in the access mask in WinNt.h or AccCtrl.h to see what it really means.

If you need some help with this, you may want to get a copy of the book Protect Your Windows Network (by Jesper Johansson and Steve Riley, Addison-Wesley, 2005). Chapter 17 goes into depth on how to analyze Security Description Definition Language (SDDL) strings and ACEs.

The permissions granted to those sub-directories are governed solely by the (A;OICIIO;SDGXGWGR;;;AU) ACE in Windows Vista, which is the biggest difference between Windows Vista and Windows XP. Rather than granting full control to the creator of subdirectories, as in Windows XP, Windows Vista grants modify privileges to authenticated users.

The net result of this new ACL is that the creator of an object no longer has any special rights, and that things are a little clearer. Perhaps the biggest change is that Authenticated Users have Modify privileges even on subfolders that are created by administrators, which is very different from Windows XP. In Windows XP, Users and Authenticated Users have no rights to objects created by administrators under the root. On the whole, though, while these ACEs may look troublesome, the net effect is not all that different from Windows XP.

To summarize, in Windows Vista everyone, including the Guest user, can read and execute files in the root. Only authenticated users can create new files and folders, and when users do, they get modify permissions on those files and folders. In other words, the permissions are marginally tighter on Windows Vista than on Windows XP, although it is worth noting that the Guest account is disabled by default.

Changes to Tokens

When a user who is a member of the Administrators group in Windows XP logs on, his token contains the Administrators group SID, and he can do anything that the Administrators group can do. In Windows Vista, on the other hand, due to User Account Control this is no longer the case. The Administrators SID is still present in the token, but is set to Deny only, as illustrated in the screenshot from Process Explorer in Figure 7.

Figure 7 Under UAC, the Administrators SID is used only for denying access unless you elevate

Figure 7 Under UAC, the Administrators SID is used only for denying access unless you elevate (Click the image for a larger view)

When performing access control, such an entry in the token is used only to deny access—in other words, to match DENY ACEs. Any allow ACEs for that SID are ignored. That means that you are not truly an administrator all the time, even if you log onto the system as one.

Integrity Levels

Windows now supports the labeling of processes and objects with integrity levels. These integrity levels are actually represented as ACEs as well, but not in the DACL. Instead, they are a part of the system access control list (SACL), with a few special flags. For example, the flag NW is used to denote blocking of a process at a lower integrity level from writing to an object at a higher integrity level (SDDL_NO_WRITE_UP). Mark Russinovich covers this at length in his article "Inside Windows Vista User Account Control" in this issue of TechNet Magazine.

Wrap Up

While there is no single, earth-shattering, modification to access control in Windows Vista, as there was in Windows 2000, there are a lot of little changes. Individually they may not seem like much, but taken together they actually mean you need to rethink a lot of what you do when you manage your system. Furthermore, these changes support a number of other initiatives, notably UAC and service hardening. Some administrators may get very frustrated when they first start using Windows Vista. I have already seen comments about "tyrannical operating systems" that restrict the ability to delete parts of the operating system that, for one reason or another, seem offensive. However, there are solid reasons for all the changes and, most likely, if you spend some time analyzing what was done, you’ll understand why.

Jesper Johansson is a security architect for a large e-commerce company, responsible for application security strategy across the range of properties and services. He has worked in security for 20 years and is the author of many articles and two books on security. When he is not working on information security, he teaches scuba diving.

© 2008 Microsoft Corporation and CMP Media, LLC. All rights reserved; reproduction in part or in whole without permission is prohibited.