Major Access Control List Changes in Vista
The fundamental structure of ACLs in Windows Vista is relatively unchanged from Windows XP. Nevertheless, there are a large number of changes that you need to be aware of. ACLs in Windows XP played a large part in several problems:
-
Most Windows XP users run as an administrator using an account that is a member of the built-in administrators group. In fact, for home users, this is a virtual certainty because all the accounts added during setup become administrators. That means that any programs they execute will execute as an administrator. Consequently, those programs have unfettered access to the operating system without the user even realizing it. This is especially problematic if those programs are of the unsavory variety.
-
The default ACLs in earlier versions of Windows made many people nervous as they included ACL entries (ACE) for Everyone, Power Users, and the like. For instance, the default ACL on the C:\ in Windows XP gave Everyone read access and granted permission to create folders for Users. In Windows Vista, it has changed slightly.
-
There was no way to assign permissions to the current owner of an object. You could give the creator owner permissions but if the owner changed those permissions were not transferred to the new owner.
-
Owners always have implicit rights to an object, no matter what permissions they are assigned on that object.
In Windows Vista, Microsoft embarked on a project to resolve these issues. In the remainder of this chapter, we look at the major changes related to access control that came out of that project, and then finish by looking at the tools you use to manage access control in Vista that are new or modified from Windows XP. It is assumed throughout that you are already familiar with how to manage access controls in Windows XP.
Least Privilege
The first of the problems listed was that of running as an administrator far too often. The problem is almost exclusively rooted in access control in that the reason people needed to run as an administrator was that none of their programs worked otherwise. However, the solution was User Account Control (UAC) . Therefore we will not go into that further here.
New and Modified Users and Groups
There are some changes to built-in users in Windows Vista. Some of them are new; some are modifications to how existing users and groups work, and a few have been removed. Each of them has some impact on how you manage access control, so it is important that you are familiar with the changes.
Administrator-Disabled By Default
The Built-in Administrator account with a relative identifier (RID) of 500, is now disabled by default in most cases. Eventually, Microsoft may deprecate that account altogether, but for now, it is disabled by default. If you have no other local accounts in the Administrators group then RID 500 is still usable in the recovery console and safe mode, but otherwise it cannot, and should not, be used. Using that account violates the important security principle of accountability as you lose ability to track who is making changes on your system.
Power Users Permissions Removed
The old Power Users group has, for all practical purposes, been removed. The group is still there, but almost all the permissions granted to it have been removed. It was not exactly a secret that a user that was a member of Power Users was effectively an administrator that had not made themselves an administrator yet. On a fully patched computer running Windows XP Service Pack 2, one of the authors, starting from scratch, granted himself administrative privileges in less than 45 minutes, and that included the reconnaissance, writing a small program in C++, and logging off and on again to complete the take-over-all because his user account was a member of Power Users.
Microsoft is planning on completely removing Power Users in an upcoming version of Windows. However, many organizations have granted sophisticated permissions to that group and rely on their users being members of it. Therefore, it was not feasible to remove the Power Users group in Windows Vista. You would be well advised to start planning a migration off Power Users, though, if you are still using them.
Trusted Installer
The Trusted Installer is, strictly speaking, not a user at all. It is actually a service. The full name for this virtual account is NT SERVICE\TrustedInstaller and its SID is:
S-1-5-80-956008885-3418522649-1831038044-1853292631-2271478464
Contrary to the SID you saw earlier for the Administrator account, this one 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 one SID is issued to a service. The display name for the TrustedInstaller service is called "Windows Modules Installer."
Help and Support Accounts Removed
The Support_xxxxxx and HelpAssistant accounts are both removed on clean installs. The Support_xxxxxx account was used to run scripts from the support center. Some OEMs that provided their own help content may also have provided their own support accounts. It is unclear as of yet what will happen to such accounts, but they are strictly speaking not necessary any longer. 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 disappear. Windows Vista has a new mechanism to accomplish this task if needed.
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 that are logging on from the network and interactively, respectively. There is also a REMOTE INTERACTIVE LOGON SID, which is assigned to users logging on via Terminal Services. Note that Terminal Services users actually will 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 Dialup-particularly to a client operating system that should not act as a remote access server in an age where more and more users are taking the perfectly sensible stance that if the only network available is a phone line, they are not online-is a bit unclear, but it is there now. INTERNET is obviously meant to denote any user that logged on from beyond the local area network. NETWORK, however, still denotes any user logging on from the network, including the Internet.
OWNER_RIGHT and Owner Rights
There is now a SID for OWNER RIGHTS. This SID applies to whoever happens to own the file at the time it is accessed. It is primarily used to restrict what the owner can do with the file. There are two primary changes to how owner rights work as compared with 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. In other words, the owner no longer has implicit full control to the object. Second, the OWNER_RIGHT SID can be used to further restrict what the owner can do with an object. An example will help illuminate this.
Let us assume we have a folder with the following ACL:
C:\Windows\system32>icacls c:\users\jesper\downloads\test
c:\users\jesper\downloads\test NT AUTHORITY\SYSTEM:(OI)(CI)(F)
Jesper-Vista\Jesper:(OI)(CI)(RX)
The user Jesper has only read permission on the folder, but Jesper is the owner. Yet, 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 received, however. If you attempt to copy a file into this folder using Windows Explorer, here is what happens.
-
Explorer tells you that you need to elevate to copy the file.
-
Explorer asks you to elevate.
-
The file copy fails because you do not have rights to copy anything into this folder. This is in spite of the fact that you are the owner.
If Jesper tries to change the ACL on the file, he will get prompted to elevate his token to do so. Because he is the owner of the file, he can still do so. The owner has implicit right 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 us add that to the previous ACL:
C:\Windows\system32>icacls c:\users\jesper\downloads\test
c:\users\jesper\downloads\test NT AUTHORITY\SYSTEM:(OI)(CI)(F)
Jesper-Vista\Jesper:(OI)(CI)(RX)
OWNER RIGHTS:(OI)(CI)(M)
In this case, if Jesper-Vista\Jesper tries to copy something into the folder, it succeeds immediately because Jesper is the owner, and has the rights to do this. However, if Jesper tries to change the ACL on the object, it will fail! The ACE for OWNER RIGHTS specifies that the owner shall have only modify privilege, not the ability to modify the 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 to either containers or objects, in other words, not applying to anything at all. That 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. Therefore, to re-enable it, you would mark it as applying to this folder, subfolders, and files, as desired.
There are several interesting scenarios where the OWNER RIGHTS SID can be useful. For example, consider the following:
-
The administrator wants users to be able to create files and folders on a file server, but does not want users to be able to change ACLs on those folders.
-
Users were members of a group at some point and created some objects. However, for business reasons, they were removed from this group after a period of time. 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 runtime, 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 the objects, the OS can keep other services from accessing them.
Default ACLs
There are several significant changes to the default ACLs in Windows Vista. First, if you are used to using Windows XP you are used to all OS files being owned by the Administrators group, and to administrators having full control over those files. That means that as a member of that group you had unfettered access to those files. This is 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 specifically to prevent a process that is running as an administrator or Local System from automatically replacing the files. This is really part of the system integrity work that went into Vista. It means that in order to delete an operating system file you need to first take ownership of the file, and then add an ACE on it that lets you delete it. It is a thin layer of protection against a process that is running as LocalSystem and has a System integrity label, but a process that has lower integrity is not supposed to be able to elevate to change ownership. Some services, for instance, can run with medium integrity, even though they are running as Local System. Those services cannot replace system files. That means that an exploit that takes over one of those services cannot replace operating system files, making it a bit harder to install a rootkit or other malware on the system.
Deny ACEs
You will find that many objects in the file system have deny ACEs for Everyone. This has caused quite a bit of consternation to many people. If you turn on the Show hidden files option, you will see the familiar Documents and Settings directory that you have known since Windows 2000. However, if you click it, you will get an Access Denied error. Few people understood what happened, and we have seen many complain about a "tyrannical operating system" that is locking them out of their files.
To understand what is going on with Documents and Settings, look at this directory listing:
C:\>dir /a
Volume in drive C has no label.
Volume Serial Number is 647C-D56F
Directory of C:\
10/04/2006 01:15 Documents and Settings [C:\Users]
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 just redirect the access to somewhere else. In this case, the junction goes to a directory called C:\Users. Microsoft has actually modified the name space of the file system significantly in Windows Vista, and the user data is now moved to C:\Users. Other things underneath the old C:\Documents and Settings\< Username > name space 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. The name space has changed so drastically primarily to make it more intuitive to users, and to get a clearer separation between documents and data. Rather than storing all data files under My Documents, developers can now create their own folders under the user's profile. Theoretically, the user will see them there and find this intuitive.
Microsoft did not remove the "C:\Documents and Settings" name space because older applications may be hard coded 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 all of a sudden, so the junction points are there for backward compatibility. These applications already break on Windows versions in languages other than English. In other words, those programs are already broken! This is really key. Quite frequently when an update to Windows, such as Windows XP SP2 or Windows Vista, breaks third-party programs it is because 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\< yourUsername >\My Documents\foo.txt, that would work, assuming you have a file called foo.txt in there. However, if you try to browse to C:\Documents and Settings\< your username >\My Documents you get the Access Denied error message. To understand what is happening, look at this ACL:
C:\>icacls "Documents and Settings"
Documents and Settings Everyone:(DENY)(S,RD)
Everyone:(RX)
NT AUTHORITY\SYSTEM:(F)
BUILTIN\Administrators:(F)
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, but if they try to enumerate the directories they represent they will fail because of the deny ACE. That is why you cannot actually see what is inside C:\Documents and Settings, nor can you delete the "directory." This is the main point of putting that deny ACE on it. It is there primarily to prevent users from deleting the junction and break older applications. It also will serve to remind developers not to code applications to use the old name space, but start using environment variables instead to insulate themselves from any future changes.
We should also mention that all these junction points are hidden by default, so the vast majority of users will never see them. To prevent those that do from deleting it Microsoft put that deny ACE in for List Folder.
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 partition), on Windows XP or Server 2003, you see this:
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 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 several differences here worth noticing. First, there are now two ACEs for BA (BUILTIN\Administrators) instead of just one. However, the net effect is the same. 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. 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). 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 potentially even possible to restore.
More interestingly, the ACE for CO (Creator/Owner) is gone. That means that there are no special permissions for the person that creates an object. If a user creates an object in the root of the file system, no special permissions are accrued to the creator any longer.
We also notice 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. Because 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 for this 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 not 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 regular user and even a Guest could create files in the root. In Windows Vista, they cannot.
There are a couple of very interesting, and on the surface, troublesome, ACEs in the two default ACLs. In Windows XP, you see an ACE inherited by containers, specifying 0x100004 for Built-In Users. That ACE grants Users the right to create subdirectories, and sub-subdirectories because it is inherited by containers. We also see an inherit-only ACE, inherited by subfolders for 0x100002. That ACE grants users the right to create files and subdirectories 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 we 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 shortcut hat 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 because you already have 0x100000 (the ability to use the object for synchronization) from the 0x1200a9 ACE. In other words, it gives you exactly the same effect as you have in Windows XP-users can create subdirectories under the root. The permissions granted to those subdirectories in Windows Vista are governed solely by the SDGXGWGR ACE for Authenticated Users. This is the biggest difference between Windows Vista and Windows XP. Rather than granting full control to the creator of subdirectories, as was done in Windows XP, Windows Vista grants modify privilege 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, and a little simpler. 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. Other than that, while these ACEs may look troublesome, the net effect is not that different from in 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.
Share Security
The default share permissions have been changed from Windows XP. In Windows XP, the default ACL on shares was Everyone:Full Control. In Windows Server 2003, and now also in Windows Vista, the default share permissions are Everyone:Read.
Using Everyone:Read as the default share permissions actually cost a fair bit in support costs until administrators got used to it. The default ACL was changed in response to outcries from a number of people that Everyone:Full Control was always a bad ACL. Clearly, the people making such cries fail to understand what Everyone:Full Control means on a share. When a subject accesses a file on a share, the operating system grants access only if both the permissions on the share and the permissions on the file system underlying the share grant the requested access. If either does not grant all required accesses, the attempt fails. This means that setting Everyone:Full Control on a share does not grant the user any access whatsoever. It merely means "I do not want to control access here." In essence, it is a way to simplify access control management by managing ACLs only on the file system, and not on the share.
Unfortunately, Microsoft listened to the people who ignored this basic fact and changed the default permissions on a share, requiring administrators to, in most cases, modify share permissions as well as file system permissions to create useful shares.
On a more positive note, Microsoft added some additional controls in the Share tab of the properties dialog box on a file, shown in Figure 1.
The new Sharing tab puts more of the controls for shares at the user's disposal. First, there are additional options hidden under the Advanced Sharing button that were not there before. Second, the user now receives a message that explains how access is managed for this computer, whether with user-name and password or if all users connect anonymously.
Changes to Token
A very important change is made to the user's security token in Windows Vista. When a user that is a member of the Administrators group in Windows XP logs on, their token contains the Administrators group SID, and they can do anything that the Administrators group can do. In Windows Vista, on the other hand, because of User Account Control this is no longer the case. As we mentioned, the Administrators SID is still present in the token, but is set to deny only. When performing access control such an ACE is used only to deny access. Any allow ACEs for that SID are ignored. That means that you really are not truly an administrator all the time, even if you log on to the system as one.
Integrity Levels
Windows now supports labeling of processes and objects with integrity levels. These integrity levels are actually represented as ACEs as well, but not in the DACL. They are instead a part of the SACL, with a few special flags. For example, the flag NW is used to denote a blocking of a process at a lower integrity level from writing to an object at a higher integrity level (SDDL_NO_WRITE_UP).
|
