If some program requests raising privileges it should do this in the secure desktop the secure desktop
is not protected by the control alt delete key sequence.
However it's well-designed designed so it's difficult to overlook
the security desk top is primarily to minimize the risk of spoofing programs in a dialog box.
The security only raises the level on the Internet.
There are programs that emulate the window asking for additional privileges
to secure desktop is also designed to draw our attention.
It's hard to overlook such a window.
Let's think about the purpose of User Account Control.
Windows users unlike users of other systems are accustomed to the fact that they work in administrative
accounts.
It says a lot of historical justification.
We log on to the Administrator account and we work on it the entire time.
It's difficult to imagine how Microsoft while ensuring the safety of users and without compromising
their reputation or the brand of their systems would have to convince all users to suddenly begin to
use standard user accounts.
All the more many programs do not run correctly if they do not have additional privileges.
This is due to what we talked about a moment ago
companies producing or creating and testing the software use the administrative account on a daily basis.
The programmer wrote the program which ran the administrative account.
Tester logged on to the administrative account and found that the program operates correctly.
No one became especially involved in testing whether the program will also run when we take certain
privileges away from it.
The User Account Control mechanism is enabled by default and its configuration is reduced to a single
dialog box.
This is probably the ugliest dialog box in all of Windows
in Windows Vista.
This configuration was more extensive in Windows 7.
It boils down to the fact that we can say how often we want to be asked whether we agree to attach the
process to an administrative token.
You've probably noticed in Windows 7 that this question is asked less often
Windows 7 designers notice that there is no sense in asking such questions.
If for example we run a trusted program such as a part of an operating system whose operation is determined
in advance and it's known what a given function is doing.
If we run a system component that's digitally signed by Microsoft it should automatically receive administrative
privileges because it does not pose any threat to the integrity of the system.
The simple fact has caused the number of questions to be greatly reduced.
Let's see then how the user account control mechanism works.
If we're still using a 32 bit operating system we'll also see how the mechanism allows running applications
that for some reason require additional privileges.
We'll see how the user account control mechanism automatically virtualise its processes in testing Windows
7 run the command line although we're logged in as a user having administrative privileges.
We've not asked for granting an additional token so the CMT X-C process runs with the standard user
privileges.
Let's go now to this system folder we're in the Windows folder.
Without any problem we can read its contents.
Let's try to write something in this folder
an error message is displayed informing us about denial of access by default standard users do not have
the rights to modify the content of the system folder.
If we now run Windows Task Manager and find our program CMD DXi it turns out that we can virtualize
it in virtualization option is automatically run for processes of third party applications.
As far as CMG is concerned it's not automatically enabled because we should not virtualize this program
we do this solely for the purpose of demonstration.
If a third party application wants to perform an operation just as we did a moment ago it will be automatically
virtual ised.
Let's see what changed.
Now the same file in the same folder can be created was a privilege to the folder changed rather not.
Maybe this file wasn't even created.
Let's check
as we can see the file exists and the fragment of some text is saved within it.
The question arises where is this file.
In order to answer this question we run Windows Explorer but we run it from this process.
Because the parent process has virtualise the newly run process will also be virtualise.
We see that a new button appeared which normally we won't find in Explorer.
When you click on this button it turns out that we can see our file.
So what happened.
Not the location of the file.
It is no longer a system folder.
It's a user folder all operations performed by the virtualization process or captured by user account
control and redirected to a folder where they can be performed.
This is a solution which is solely intended to enable older and poorly written applications to run.
This is why virtualization is not available in 64 bit Windows.
Microsoft's assumption is that the transition from 32 to a 64 bit platform is the equivalent to the
transition to a higher quality.
Here there should be programs written so that they work properly with standard privileges and do not
have to be virtual ised.
Unfortunately the only program that fully incorporates the integrity level mechanism and the user account
control.
Up to now is Internet Explorer this same Internet Explorer running on Windows 7 and on Windows XP offers
completely different levels of security in Windows XP.
It's not run in protected mode in Windows 7.
It's run by default.
How was it done.
In one of the earlier lectures we said that the Internet Explorer process runs on a low level of responsibility.
Therefore it cannot modify anything that is located at higher levels of responsibility
if the user would like to perform such an operation.
The proxy i.e. user X-C is used to use this proxy we have to explicitly agree to this.