Why Can't I Access My Files?
This question is usually accompanied by some explanation, of varying degrees of clarity, that the author wants to delete or modify a file in %ProgramFiles% or %SystemRoot%. Alternatively, the user is trying to modify a file that Administrators have access to. Consider this scenario: Let's say we have some file that looks as follows:
C:\Users\test>icacls foo.txt
foo.txt NT AUTHORITY\SYSTEM:(F)
BUILTIN\Administrators:(F)
We are logged on as a member of the Administrators group:
C:\Users\test>whoami
jj-vistartmtst\jesper
C:\Users\test>net localgroup administrators
Alias name administrators
Comment Administrators have complete and unrestricted access
to the computer/domain
Members
------------------------------------------------------------------------
Administrator
Jesper
The command completed successfully.
If you try to delete this file, however, you get the following response:
C:\Users\test>del foo.txt
C:\Users\test\foo.txt
Access is denied
At this point the user frequently launches into a rant about "tyrannical operating systems" that "block me from doing what I want with the software I have bought and paid for …"
Ignoring the rant for a moment, the answer to why you cannot delete this file should be relatively obvious. With UAC enabled, even members of the Administrators group have a token that has the Administrators SID set to disabled. In other words, Administrators have full control over the file, but you are not an administrator, yet. To access this file you must elevate. You can do that by launching an elevated command prompt, or by changing the ACL on the file, and using the COM Monikers in the ACL UI to elevate. You cannot, however, elevate an Explorer window, which brings us to our next question.
Why Can't I Delete Stuff If I Elevate Windows Explorer?
So, in frustration over the "tyrannical operating system" the user now elevates an instance of Windows Explorer. He right-clicks on Windows Explorer (see Figure 1).
Then he goes through the elevation motions … (see Figure 2).
An Explorer window pops up, and he attempts to delete the file (Figure 3), and the following dialog box shows up:
At this point various colorful language and threats of physical violence ensues. Yet, the problem is quite simple. Recall that we said earlier that you cannot elevate explorer.exe! Each user can have one and only one instance of explorer.exe, and you have one running your desktop already. Therefore, elevation of explorer.exe is barred, even though the OS for some reason lets you go through the motions of trying. If you inspect the token for your "elevated" explorer.exe you will find that it, in fact, never launched a new instance of explorer.exe after all. It is just another window to the same instance that is still running with a filtered token.
This behavior becomes even more interesting when the user tries to delete or modify some part of the OS. For instance, let's say the user has decided that Internet Explorer really offends him for some reason, so he tries to delete it.
C:\Windows>del "c:\Program Files\Internet Explorer\iexplore.exe"
c:\Program Files\Internet Explorer\iexplore.exe
Access is denied.
This is easily explained. Administrators only have read-access to operating system files:
C:\Windows>icacls "c:\Program Files\Internet Explorer\iexplore.exe"
c:\Program Files\Internet Explorer\iexplore.exe NT SERVICE\TrustedInstaller:(F)
BUILTIN\Administrators:(RX)
NT AUTHORITY\SYSTEM:(RX)
BUILTIN\Users:(RX)
Successfully processed 1 files; Failed processing 0 files
To modify the ACL you would first have to change owner of the file. The icacls tool also allows you to set the owner of a file, but due to what is likely a bug in the original release of Windows Vista, it cannot solve this particular prob lem because Administrators do not have permission to change the owner on protected files. An elevated token does contain the SeTakeOwnershipPrivilege, but it is disabled. Icacls does not enable it before attempting to change the ownership. Therefore, icacls cannot be used to take ownership of protected OS files. To work around this you can either take ownership in the GUI, or use the takeown.exe tool to change the owner. Once you own the file you can modify its ACL and grant yourself permission to delete it.
How Do I Disable UAC?
If you want to disable UAC entirely you can do it a couple of different ways. If you want to do it on a single system, you can do so with the User Accounts control panel applet, as shown in Figure 4.
If you need to turn off UAC on a whole fleet of computers the easiest option is to use Group Policy. The setting that governs UAC is the "User Account Control: Run all administrators in Admin Approval Mode" setting. If you set it to Disabled, you turn off UAC. Doing so requires a reboot.
What Happens If I Turn Off UAC?
If you turn off UAC you need to remember that you lose all the protection it affords, including Internet Explorer Protected Mode. Internet Explorer now runs with the same rights as it did in Windows XP, which means that, if you are logged on as an admin, one bad click can compromise your entire system. You do not just lose the prompts if you disable UAC. This is why we recommend that if you dislike the prompts you should enable automatic elevation instead to retain at least some of the protection UAC gives you. Of course, if you have to click an inordinate number of prompts you might also want to consider what you are doing with this computer because in day-to-day use we rarely see any elevation prompts at all. We highly encourage you to leave it on for a couple of weeks. You will likely have a decreasing number of prompts over time.
What Access Do Low Processes Have to High Processes?
The short answer is, very little without taking hostile action. The slightly longer answer is that it depends on how the high-integrity process is executed. Earlier we discussed the UIAccess flag. Setting this flag enables a low-integrity process to use the SendMessage() API to send window messages to a high-integrity process. If the flag is not set on the process, then most messages are filtered.
It is interesting to note that the Logon SID has Read Memory rights to elevated processes. However, even though a process running with a filtered token has the same Logon SID it does not have the right to read memory. The reason is that the integrity controls in Windows Vista do not follow a strict Biba model. In the Biba model a lower integrity process could read higher integrity data but not write it. Biba is a "read up, write down" model. The Windows Vista integrity model permits only "read down, write down."
This means that the only legitimate access a process running with a filtered token has to a process running elevated is the ability to query limited information and to use the elevated process for synchronization. This corresponds to the PROCESS_QUERY_LIMITED_INFORMATION and SYNCHRONIZE flags. PROCESS_QUERY_LIMITED_INFORMATION is a new right flag with Windows Vista which allows you to query for the full name of the executable image that was used to launch the process.
It is really important to note, in this context, however, that UAC was never designed to establish a security boundary between processes on the same desktop. Therefore, there will always be ways for a malicious process to interact in undesirable ways with an elevated process on the same desktop. This is simply a design limitation of UAC. Recall from the goals we mentioned earlier that process isolation was not a design goal of UAC. Do not rely on UAC to keep you safe from malicious code.
Why Does the Screen Have to Go Black?
The screen goes black, or more correctly, a transparent black, when the OS presents a UAC elevation prompt on the secure desktop. As we discussed, elevation prompts are shown on the secure desktop to prevent tampering with them by unelevated processes on the user's desktop. The secure desktop does not permit programmatic access. Therefore, for sensitive tasks, such as credential entry and UAC, the secure desktop permits a measure of process isolation. This behavior can be disabled using the "User Account Control: Switch to the secure desktop when prompting for elevation" group policy security setting. If it is disabled the prompts are shown on the user's desktop instead, but this significantly reduces the security of the elevation process and we recommend you leave the default turned on.
Some users have complained of significant delays in this switch to the secure desktop. These are most likely caused by driver issues with the video card. It is also possible that they can be caused by a very slow video chip. With even moderately speedy hardware, such as that found in a standard-issue corporate laptop, the delay is minimal.
I Don't Need UAC; Can I Just Enable It for Other Users?
No, you cannot enable UAC per user. UAC is a system-wide setting, and quite frankly, we believe that everyone can benefit from UAC. This is particularly true if one considers that the ability to run exposed processes, such as Internet Explorer, in a protected sandbox disappears if you disable UAC.
If you absolutely cannot stand UAC you can enable automatic elevation for admins in admin-approval mode using the "User Account Control: Behavior of the elevation prompt for administrators in Admin Approval Mode" group policy security setting. However, you need to realize that when you do that any malware you run, whether by accident or intentionally, has full access to your computer. Therefore, we highly recommend you do not enable automatic elevation and develop a way to work with UAC that allows you to retain your level of protection. One method that does work well for some users is to enable automatic elevation for admins and then use two accounts. One account is a standard user and is used for day-to-day tasks. The other account is an admin and is used for admin operations. While reading e-mail and surfing the Web, use the standard account. When you need to perform an administrative task you can use FUS, as shown in Figure 5, to switch to the administrative account. Windows Vista supports FUS even in domain-joined situations, contrary to Windows XP.
What About Remote Access?
Remote access via Windows Networking (SMB) is primarily impacted on stand-alone computers, as mentioned earlier. On domain-joined computers remote access using SMB works exactly like Windows XP. To turn off the generation of filtered tokens for remote access with local administrative accounts on a stand-alone computer, set the LocalAccountTokenFilterPolicy registry key as shown earlier.
Why Isn't UAC More Like Sudo?
A very common complaint from those familiar with Unix is why UAC couldn't be more like sudo. For the uninitiated, sudo is a method in Unix to run commands as a different user, typically the root user (equivalent to the built-in Administrator in Windows). An administrator uses a file called sudoers.conf to define which commands may be executed by which users. As long as a user is permitted to run a particular command in that file the user may type sudo in any command shell and the command will execute as root.
Sudo has proven very long-lived. Used properly, it provides a convenient and very sensible way to elevate particular tasks. Used poorly, it makes every sudoer root. We find that the poor implementation is far more common.
In a sense, sudo provides a convenient way to become root for a particular task. This is actually one of the primary reasons why sudo is quite different from UAC. The purpose of sudo is simply to allow a non-root user to run a root command. The purpose of UAC is much more than to allow users to become omnipotent for particular tasks. As we discussed above, UAC is first and foremost about allowing more users to do more things without being omnipotent at all. Unix was originally designed to permit that, but Windows has been suffering from a legacy of operating systems without any security model at all for almost 20 years now.
It is also important to keep in mind that when building UAC, Microsoft took the quite sensible approach that it was better to build something that leveraged the strengths of the Windows architecture than to build something that was designed for the Unix architecture. The two technologies, therefore, are similar, but at the same time, very different.
Sudo has a great advantage over UAC that it can theoretically restrict access to only certain commands. UAC does not permit an administrator to delegate a specific command to a user. On the other hand, in practice, this function is relatively rarely used as it becomes very cumbersome, and many of the commands that would be delegated indirectly confer administrative rights on the user anyway. For instance, if the administrator delegates editing of a cron job that runs as root to a non-admin user, that non-admin user can easily become root by editing the cron job. In UAC, Microsoft instead tried to enumerate all the commands that could confer admin rights, and require a UAC elevation for those. Of course, Microsoft did not achieve a complete enumeration, so there remains a large number of tasks that are quite innocuous, but which require elevation. For instance, access to the registry editor requires elevation if the user is a split-token administrator, even though large parts of the registry cannot be used to elevate privileges.
Sudo also is very good because it allows delegation to individual users without making them administrators. A user can be granted the right to perform a single task. To do the same in Windows Vista, the user would have to either be a member of the Administrators group, or be provided with the password of a member of the Administrators group. This is perhaps the greatest benefit to the sudo approach versus UAC. With UAC, the user must be granted effectively unfettered access to the system to be able to elevate even a single task. Sudo, by contrast, allows creation of effectively custom administrators. Of course, from a realism perspective, there is a really good chance that they all become effective administrators after you are done. To be totally pragmatic, Microsoft's approach of making their administrative status so obvious is appropriate when faced with the choice of hiding it behind a lot of seemingly innocuous commands.
On the other hand, sudo was designed for a Unix command line environment, not a Windows GUI environment. UAC was designed to take advantage of the environment it was being used in, and manages to do so quite well. In addition, sudo is vulnerable to attacks from malicious programs run as a non-elevated user. For instance, if a user has sudo rights to a sensitive program, like a shell, then another program that the user executes could call sudo and now have privileged access to the operating system. It is a well-recognized fact in the Unix/Linux community that if an attacker gains access to an account from which you run sudo to perform administrative tasks, the attacker has won. This, of course, is exactly the same in Windows.
Taking advantage of the GUI environment in Windows, UAC, by default, switches to the secure desktop for the elevation prompt. This makes interference attacks from processes that run on the user's desktop much more difficult, although not by any means impossible. Some consider the prompt extremely annoying, but it is an integral part of the security of UAC. The secure desktop does not permit its interface to be driven programmatically. Therefore, a malicious program executing in the users non-elevated context cannot programmatically invoke an elevation and respond to the prompt. As long as the secure-desktop switch behavior of UAC is not disabled, this provides a reasonable degree of assurance that the user intended to elevate.
Sudo does also have some benefits that UAC simply cannot match. First, it provides far better logging than UAC. In the following section we discuss how to audit elevation events. With sudo, however, you can audit much more than just the elevation itself. You can audit more or less everything the user did after the elevation. Of course, if an attacker has sudo rights to certain commands the attacker can tamper with the syslog and interrupt the event flow.
Sudo also permits definitions of hosts, IPs, host classes, and so, in which sudo is valid. This can be used to allow a user to execute remote commands as a different user, but only on particular hosts. Windows and UAC simply have no counterpart to that.
Finally, sudo has a system that permits caching of the credentials for a period of time, by default, 15 minutes. This means that the user does not have to re-enter the password for the target user when elevating another task within 15 minutes of the last elevation. This, however, is actually a security risk. If a malicious application is running on the system, or manages to run within the same controlling terminal that you executed the elevation in, the malicious application could elevate without further user input. To avoid this type of attack, Microsoft did not build functionality to cache passwords entered for elevation.
How Do I Audit Elevation?
One area where UAC definitely falls behind technologies with similar functionality, such as sudo, is in auditing. To turn on auditing for UAC elevation you need to configure both success and failure auditing of process tracking. Unfortunately, this is one of the noisiest audit categories in Windows. A single UAC elevation causes around 10 events with IDs 4688 (Process Creation), 4696 (A primary token was assigned to a process) and 4689 (Process Termination).
| Note |
Event numbers in Windows Vista have changed from those in Windows XP. Many of the events have additional information in them, and consequently have a different structure than they did in Windows XP. Event log management systems typically key off the event ID and the source to determine how to parse the event. If the structure of an event changed, but the source and event ID remained the same, it is highly likely that many event log management systems would encounter severe problems parsing the events. Therefore, the events that were modified were renumbered. To find the new number of your favorite event from Windows XP, take the Windows XP event number and add 4,096 to it.
|
To determine which process was elevated and as which user, you need to correlate two events: 4688 and 4696. For each process that was elevated you will find one event 4688 that shows you which process was created. The process, however, is initially created under the LocalSystem account, as shown in this event:
Log Name: Security
Source: Microsoft-Windows-Security-Auditing
Date: 1/12/2007 6:57:28 PM
Event ID: 4688
Task Category: Process Creation
Level: Information
Keywords: Audit Success
User: N/A
Computer: JJ-VistaRTMTst
Description:
A new process has been created.
Subject:
Security ID: SYSTEM
Account Name: JJ-VISTARTMTST$
Account Domain: WORKGROUP
Logon ID: 0x3e7
Process Information:
New Process ID: 0x9f8
New Process Name: C:\Windows\System32\cmd.exe
Token Elevation Type: TokenElevationTypeFull (2)
Creator Process ID: 0x5b4
Token Elevation Type indicates the type of token that was assigned to
the new process in accordance with User Account Control policy.
Type 1 is a full token with no privileges removed or groups disabled.
A full token is only used if User Account Control is disabled or if the
user is the built-in Administrator account or a service account.
Type 2 is an elevated token with no privileges removed or groups
disabled. An elevated token is used when User Account Control is
enabled and the user chooses to start the program using Run as
administrator. An elevated token is also used when an application is
configured to always require administrative privilege or to always
require maximum privilege, and the user is a member of the
Administrators group.
Type 3 is a limited token with administrative privileges removed and
administrative groups disabled. The limited token is used when User
Account Control is enabled, the application does not require
administrative privilege, and the user does not choose to start the
program using Run as administrator.
Note the Token Elevation Type and the associated description below. Events with TokenElevationTypeFull indicate a process that was created during a UAC elevation.
To find out which user account was used in the elevation, look for an event 4696 that has the same process ID as the New Process ID field in the 4688 event. This event is shown here:
Log Name: Security
Source: Microsoft-Windows-Security-Auditing
Date: 1/12/2007 6:57:28 PM
Event ID: 4696
Task Category: Process Creation
Level: Information
Keywords: Audit Success
User: N/A
Computer: JJ-VistaRTMTst
Description:
A primary token was assigned to process.
Subject:
Security ID: SYSTEM
Account Name: JJ-VISTARTMTST$
Account Domain: WORKGROUP
Logon ID: 0x3e7
Process Information:
Process ID: 0x3f8
Process Name: C:\Windows\System32\svchost.exe
Target Process:
Target Process ID: 0x9f8
Target Process Name: C:\Windows\System32\cmd.exe
New Token Information:
Security ID: SYSTEM
Account Name: Jesper
Account Domain: JJ-VistaRTMTst
Logon ID: 0x15ef5
This event shows us that the system assigned a new token for the user JJVistaRTMTst\Jesper to this process. This happens before control of the process is handed over to the user but demonstrates that the process is actually launched by the system, not by the user.
Only by combining these two events can we tell (a) that a process was created and (b) which user it was created as. Note that we still cannot tell which user initiated the elevation. This functionality does not exist in Windows Vista, unfortunately.
