UAC and Virtualization - some infos for all

Seems I have the need to dig a little deeper into all of this, so off I went. Here is some data that I put together based off all the MSDN documents I have been reading. May not be 100% correct, but I am only repeating what M$ themselves state, so it should be.

_____________________________________________________

Virtualization - A simple explanation

Most users of Windows 2000 or XP did not know it, but were logging in with Administrators accounts. A user account, the user-name you log into Windows with, is a member of one or more groups. Each group in Windows has certain rights or priveleges. The most common groups are the Administrators and the Users groups.

Members of the Administrators group have full access to the entire operating system. Administrators can install programs, modify or delete files and read or write to any directory or anywhere in the file system. Administrators enjoy being free to do as they please.

Members of the Users group do not have full access to the operating system. They are denied access to important system directories such as c:\windows and c:\program files. They are denied access to most of the registry. Users have full access to thier "User Profile", that is the area where all of thier personal data is kept, such as the "My Documents" directory. A User is allowed to create new directories in thier profile directory and the c: drive.

Many security exploits have been successful due to the fact that prior to Windows Vista, the default account that users logged in with was a member of the Administrators group. Since most users logged in with this account and the full rights that went with it, anything they executed had rights to do whatever it pleased. On one hand it made installing programs easy, but on the other it made viruses and malware prolific becuase one a virus was started, it had the rights of an Administrator because the user that started it did as well.

Most programs of that era were written with no special concern as to whether they wrote data in areas like c:\windows, c:\program files or an area of the registry like HKEY_LOCAL_MACHINE. There was no need to write to the user profile area because they weren't restricted to doing so in most instances.

As more and more computers became infected or exploited, M$ began to shift thier approach for ordinary home users starting with Vista. In Vista, they created the default account as a member of the Administrators group still, but introduced User Account Control, or UAC. In a nutshell what they did was to model it so that the average user was now a member of both the Users group and the Administrators group. Further, they used UAC to fill the gap between the two.

In Vista, they also changed how they wanted programs to be built. They wanted programmers to include what is called a manifest with thier programs. This manifest declared if the program needed Administrators rights or not - whether the program needed to write/modify in protected areas. If a program included this information, then Vista could use UAC to provide a "consent prompt" to the user. The "consent prompt" was an easy way to ask the user "This action requires the rights of an Administrator, of which you are one. Would you like to let this action happen?"

This is considered by many to be a new security feature. However, it is not. It is a temporary method to ensure that old software still works in Vista and later versions. It is meant to "nag" programmers into creating programs that dont' need to write into protected areas.

If an older program, without a manifest, were to be executed on Vista, there was no indicator that it should be elelvated to Administrator rights. If the program did not write/modify items in protected areas, then the program would work as it should. If the program did attempt to write/modify items in protected areas, it would fail. It would fail because by default Vista used the rights of a User rather than the rights of an Administrator.

In Windows XP it was possible to be a User instead of an Administrator. In order to use many programs you would have to give alternate credentials to a program when you started it. For example, you would have to "Run it As" an Administrator by giving it the username and password of an Administrator account. This was known as the "RunAs" command.

In Windows Vista, M$ did not want to inconvenience millions of ordinary home users with having to type in an Administrators username and password for the thousands of programs that were written that would require it. Instead they created UAC. UAC has the job of determining what needs to be elevated to Administrator rights and then presents a very simple "Permit or Deny" prompt for the user to decide.

But there is a problem with this approach. Since ordinary home users likely don't understand most of this, and many applications did not have a manifest, there was a high probability that many older programs would not work properly and UAC could not determine when to ask for elevation.

Virtualization was implemented to tackle this problem. It is stated, in many places, that UAC and virtualization are a temporary fix. UAC has the job of reading a programs manifest, then asking the user for Administrator rights for the program if it needs it. When M$ decides programmers have had enough time to change thier ways, or that enough time has gone by that people need to stop using old non-compliant software, they will remove UAC in favor of standard user account practices.

In the meantime, consumers have bought and use programs that are not compliant with Vistas UAC (they have no manifest). Rather than have the users input alternate credentials, Vista introduced virtualization. When virtualization is enabled, programs that were not elevated to Administrator rights with UAC will still be able to operate "as normal" even though they are designed to write/modify in protected areas.

When the OS detects that a non-elevated program tries to write to a protected area, it redirects the write/modify action to a defined area. In the case of the registry, if a program tries to write/modify to anywhere but HKLM\Software, it is denied. If a program tries to write/modify to HKLM\Software\Classes, HKLM\Software\Microsoft\Windows or HKLM\Software \Microsoft\Windows NT it is also denied. Each key then in HKLM\Software, other than the noted exceptions, can be virtualized. In addition, each key can be controlled as to whether it can be virtualized.

When a registry key is virtualized, the attempt by the program to write to it fails, but is transparently redirected to a user defined area in the registry. This typically is located at HKEY_USERS\<User SID>_Classes\VirtualStore\Machine\Software. The "virtual store" holds the value, and when the program runs again, it reads the virtual area just the same as the real area. In fact, a value in the virtual area holds precendence over the real area - it will be used before the real values.

File virtualization works in much the same way. When the program attempts to write/modify to a protected area, the action is allowed but it happens in the virtual area. The virtual data is stored in c:\Users\<UserName>\AppData\Local\VirtualStore\ directory. Just as the registry, the virtual files have precedence over the real files if they exist.

Virtualization allows the newer operating systems Windows Vista and Windows 7 to allow older programs to be used that do not comply with working properly in a User environment. UAC is employed to allow ordinary home users a convenient way of elevating to Administrator when needed without inputting alternate credentials. UAC is used to encourage programmers to adhere to writing/modifying in user profile areas. Virtualization, for the time being, allows programs that need Administrator rights to operate "as normal" without being affected by the virtualizing that is being done on thier behalf. I have seen no roadmap on these features to indicate how long they will remain. The only indication, that is repeated over and over and over, is that all of this is temporary. It may well be that these features remain forever considering how cleverly they can be put to use.

Sul.

 

And here are the registry values relating to UAC, located at
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System]

Nothing new here, but I had a need to put them together so I though someone else might find it useful too.

Code:

ConsentPromptBehaviorAdmin	DWORD	Default = 5
0 = elevate without prompting
1 = prompt for credentials on the secure desktop
2 = prompt for consent on the secure desktop
3 = prompt for credentials
4 = prompt for consent
5 = prompt for consent for non-Windows binaries

ConsentPromptBehaviorUser	DWORD	Default = 3
Controls behavior of the elevation prompt for Standard Users
0 = automatically deny elevation requests
1 = prompt for credentials on the secure desktop
3 = prompt for credentials

EnableInstallerDetection	DWORD	Default = (home = 1) (enterprise = 0)
Control the detection of installation packages that need elevation consent
0 = disable detection of installation packages
1 = detect if installation requires elevation

EnableLUA	DWORD	Default = 1
Controls whether Admin Approval Mode is enabled
0 = disable
1 = enable "Administrator in Admin Approval Mode" and also enable all other UAC policies

EnableSecureUIAPaths	DWORD	Default = 1
Only elevate applications that are installed in secure locations (sys32 or program files)
0 = Disabled
1 = Enabled

EnableUIADesktopToggle	DWORD	Default = 0
Allow applications to prompt for elevation without using secure desktop (faded desktop)
0 = Disabled
1 = Enabled

EnableVirtualization	DWORD	Default = 1
Controls whether application write failures are redirected to defined file system and registry locations. This setting applies to applications that write application data to %ProgramFiles%, %Windir%, %System32% and HKLM\Software
0 = applications that write data to protected locations fail
1 = applications that write data to protected locations are redirected (upon failure) to defined user locations 

FilterAdministratorToken	DWORD	Default = 0
Controls behavior of Admin Approval Mode for the Built-In Administrator account
0 = The Built-In Administrator account runs all application with full privileges
1 = The Built-In Administrator account uses Admin Approval Mode which requires elevation consent

PromptOnSecureDesktop	DWORD	Default = 1
Controls whether elevation consent prompt is displayed on the users desktop or the secure desktop (faded desktop)
0 = elevation consent prompts go to the users desktop
1 = elevation consent prompts go to the secure desktop (faded desktop)

ValidateAdminCodeSignatures	DWORD	Default = 0
Controls whether applications require a proper signature to be elevated and permitted to run
0 = disable enforcement of validation before executable is permitted to run
1 = enable enforcement of validation before executable is permitted to run

Sul.

 

Hey Sully
Thank you Sul for a very enlightning and interesting reading, it gave me something to think about.
Best Regards.

 

Silent elevation can be secure
Elevate without prompting does enable protectedmode (Low rights) and virtualisation and UAC protection (at least when you install from safe locations, disable installer recognition and allow only signed programs to run elevated, allow only signed drivers to install)

So for you Sul you can stay away from UAC as the retarded HIPS, allow me, allow me, allow me (allthough Win7 default works okay for most)

How to enable through registry

https://www.wilderssecurity.com/showthread.php?t=282550

Where it is stored

https://www.wilderssecurity.com/showpost.php?p=1753842&postcount=16

Until when will it be supported
Windows 9 won't have virtualization for sure. A reliable source at M$ presented this (Mark Russinovich) at a early spring 2008 security seminar in London. This presentation was full of UAC details. I was (am) angry on myself that I lost this valuable pdf. After my XP to Vista conversion, teh PDF could not be hacked from the website anymore. The presentation showed the limitations of UAC. The guidelines on how to achive total isolation (like Chrome does) was also outlined (important assigning a job to deny access to user handles and running on an alternative desktop to stop messaging to services etc).

1) Objects of same rights are allowed to infect each other. Now everything runs by default Medium rights, so this is an issue. When all objects from threat gates run Low Rights containers this is a non-issue.

2) USB is ommitted, because SOX and good Endpoint practise should deny read/write access to these ports. For companies determined to allow client side data intrusion, special password protected encrypted USB drives with own GUID should be used. Current policies provide these mechansims allready.


Discaimer: Allthough I used the quote, this is how I remember it. Marc called it Pseudo Admin through virtualisation (in fact running Medium Rights).

Regards Kees

 

I'm wondering if Windows will, by design, protect anything within user-space. Let me try to explain better. As it is right now, it won't protect anything within the user-space. Unless some objects run with Low IL, which won't be able to create/modify. But, for example, Google Chrome installs to user-space. While this is a good thing, it will leave the program prone from tampering by malware, considering the malware is running with Medium rights as well.
It would be great if, by design, Windows would protect any program installed within user-space. A sort of a new Program Files dir, but used for the current user, where the user wouldn't be able to write to/delete/modify without permission.

That's one of great things of running a standard user account. The user has no writes to mess with Program Files dir, which protects against malware tampering.

 

Hi Sully, Kees,

have you guys seen this MS UAC Processes and Interactions article, that I've linked to many times before in this forum like a broken record /LOL. Anyway, it seems to state unequivocally that in admin approval mode, the administrator is launching applications not needing to perform administrative tasks with a standard user token, so this is why I, for one, have perceived UAC as offering at least some security benefits to the user who wants to run as administrator.

BTW, thanks again for devoting what must be a tremendous amount of your time researching all this and explaining it to us in language we can actually understand

 

Wouldn't it be just as easy to continue installing applications to program files and only housing the configurations etc in the user profile? Why would you want to create a program files type area within the user profile if you desire it to behave in the same way the c:\program files already does? Please expand on your idea. I for one am interested to hear why you would say that.

Sul.

 

Hello,

I think you misunderstood what I tried to say.I'll see if I can explain myself better.

Current Windows scenario: Pretty much all applications are installed to %PROGRAMFILES% dir. This is nothing new. It's also nothing new that a standard user, or an Admnistrator forced to run with Medium rights by UAC, cannot write or modify %PROGRAMFILES% dir.

This behavior helps protect these programs against tampering by malware.

Then, and it was just something that crossed my mind, I was wondering if it would be possible, or even doable for that matter, to protect installations done within the context of the user. I gave Google Chrome as an example.

It installs to user-space, rather than %PROGRAMFILES%. (Sure, one can move it towards %PROGRAMFILES%. But, lets leave this option aside.)

This leaves Google Chrome installation folder open to tampering by malware, if malware runs with Medium privileges. If the user can create/modify/delete within his/her own user-space, then so can malware.

So, I wonder why Microsoft (Windows) won't protect program installations done to user-space against unauthorized modification, just like what happens with %PROGRAMFILES%, by only giving the read and execute rights to those applications folders that install to user-space.

Basically, what I am suggesting is that whatever gets installed to user-space becomes protected against unauthorized write and modification.

Again, I have no idea if such could be done or easily done. Just something that crossed my mind.

I hope to have clarified my idea a bit more. (And, I hope not to have confused you more! )

 

No, I am not confused. I understand what you mean. But I don't really understand why this would need to be done. It most certainly can be done. You could do it yourself with the same syntax I sent you regarding security templates. I have done this sort of thing.

However, what is the reason to keep Chrome in user space? If a user can modify his own profile area, why would you want Chrome install there? As default the Chrome handler runs at Medium, and all "tabs" run at low. It is the same whether it lives in Program Files or user profile AFAIK. You are stating that if the user executes something, such as a virus, at medium integrity, that the process can then modify the Chrome install in the user profile because the rights say it can. This is true. but then you state that M$ should come up with a way to protect programs installed to user profile area. But again I cannot help but think, why? If it is a concern that something might get modified by the user themselves, the concern is already addressed by housing the program in program files, and the profile in user space. Then malware/virii that modify the profile for Chrome don't get much done, only preferences.

If you disregard chrome, what other programs would you install to user space? What are the reasons to do so? Why would they not be better of in program files? Truly, while I don't really see why another area like program files should be created in user space, your line of thought tickles my curiosity. What would be the advantage of having the program data living in user space over program files?

Sul.

 

Yes, I know it can be done. At the time I was writing, I was thinking of other stuff, non-relevant for this matter, which lead me to say I wondered if could be easily done. No idea why I thought about them...

Anyway, yes I'm aware it can be done. Security templates are a treat.

Sorry, my first comment had in mind that, eventually, UAC will disappear. UAC was a mean to force programmers to code applications that won't require to be installed at system level, rather at user-space.

If this happens, and if virtualization no longer is the scenario, then that means that applications install at user-space level. So, this means that, a standard user account, which runs with Medium rights, for example, everything with Medium rights can interact with other objects with Medium rights, and this includes malware.

Also, I guess that an Administrator account would, in its turn, run with High? (Considering there would be no UAC.)

So, assuming that an application gets installed to user-space, it will need protection. Or, at least, I see it that way. Otherwise, wouldn't this be an old scenario like Windows XP?

Sure, applications wouldn't be installed to user-space in XP. They would be installed to Program Files dir, which made many users always run as Administrators.

What Microsoft expects to achieve is that applications wouldn't require such thing. Meaning, users would all start using standard user accounts. But, except from objects coming from Low IL, like internet facing applications, all would run with Medium, and if an infection occurs with Medium rights, then what is there to protect applications from being compromised by malware?

The answer is that it would either be placed at Program Files dir, but isn't that what Microsoft is trying to fight?
And, if applications are installed to Program Files dir, isn't things going back in time? And, if UAC no longer exists and virtualization gone, then how will a standard user run most of his/her applications, if they install to Program Files dir? (This reminds me of XP.)

You mentioned yourself in your first post

 

Situation: Family computer.

Will the security you are talking about prevent a child from running an executable from a USB drive?

​

Or copying it to the desktop and running it?

​

thanks,

rich

 

Rmus, you do make a good point, actually. I didn't even consider that scenario.

Which also makes me wonder what would be set in place, that would be available in all future Windows versions (Knowing Microsoft, they will keep the business model of restricted versions and then better stuff in the more expensive ones.), to allow to deny such.

But, all I wanted to point out in my previous posts was that, if UAC does indeed disappear, which it seems to, along side virtualization, once applications installs and run from user-space, then no application within user-space would be safeguarded against malware tampering (unauthorized access).

One way to protect them would be to still install them under Program Files dir, and user a standard user account, which is Microsoft goal (the standard user accounts). But, this would then bring the same old problem: If applications are placed within Program Files dir to be protected, then it's the same hassle to work with them, as it happened Windows XP. (I never worked with Windows XP, but I believe, according to a lot of people, it was a living hell to work with applications under a standard user account, and that because, all applications were installed at system level.)

So, if the dream/goal of standard user accounts is achieved, then what will protect those applications?

In current scenario, under Vista and 7, most of applications install at system level, and are protected from tampering in both standard user account (restricted rights) and Administrator (applied by UAC).
That's why I place stand-alone applications under Program Files dir, for easier and faster protection. Because, if ran from user-space and without any limits applied, then any other Medium level object (and I'm thinking malware) can screw it up. Now, this is to be avoided. But, it does not seem to be what will happen in future, if all applications are to be installed to user-space. There needs to exist protection, like only allowing read and execute rights to whatever gets installed to user-space.

Edit: What would be the point in running applications from user-space if malware can infect them all?

By the way, I'm not sure if you were asking it to me.

 

If you are referring to the bit of security UAC offers, no it will not, but a child using my computer will run only in a Standard account with AppLocker enabled, so the attempted launch of the executable will get nowhere. Not even the installation to user space such as the My documents directory. Even without AppLocker, the executable could only install to user space, so its effectiveness would be limited (at least making its removal easier) because it can't breech the primary directories such as %Programfiles% or %Windir% of the O/S. As implied by the link I provided, UAC in Admin-Approval mode reduces common applications to Standard user level rights.

 

Thank you for that! And also for the screen shot of AppLocker in action. That's the first I've seen.

In my view this is the only really secure solution: security in place to prevent the running of *any* executable not already installed.

The children shouldn't be able to run even little games without the parents' permission.

----
rich

 

You're welcome. To clarify, the top alert is the standard one in Windows 7 Ultimate for an AppLocker block, while the alert underneath is a customized alert created in Task Scheduler.

Right, but I would extend that restriction to teens and adults as well, where if anything is to be permitted, it's allowed only by the Administrator (effectively the owner) responsible for the computer in question. I know of an adult who is highly irresponsible at what he does regarding installation of dubious games, screensavers and other binary paraphernalia on the work pc no less.

BTW, EasyBCD is actually already installed, but was done so in the administrative account (by me), but AppLocker will prevent anything from launching by selected users, if setup that way.

 

Agreed!

----
rich

 

I see now. You treat UAC and virtualization as a security method, so you wonder what happens once it is removed, how can you have the same type of security. Makes sense from that angle.

I don't think M$ wants software that is located in the users profile. On the contrary, I think they want it located at program files directory. I think they want Admins to install the programs, and they want the data and configs to be written to the user space somewhere. This is why UAC going bye-bye should not effect anything once it happens. This is why once virtualization goes away, only properly made programs will work smoothly. The program files directory is a perfect place for your programs. You can, as a user, read and execute there, just how it should be. A proper program would create configs and settings then in the user space or the HKCU. Improper programs would try to do it in program files and HKLM, exactly what makes LUA such a pain.

Most programs do something to another object. Modify a picture, make a movie, create a document, burn a cd, play a game. All typical actions that the program does are performed on files that the user has access to, such as thier user space or another hdd or usb drive. When was the last time you installed a program to use whose sole purpose was to modify/delete data in program files or windows directories? Oh, there are some, but they are special tools, not the norm. The problem is that the programs seek to store thier data in program files or they wish to modify thier settings in HKLM.

UAC and virtualization will be around I believe longer than planned simply because they do offer some nifty security enhancements. Perhaps as long as a lot of software is still made "incorrectly" and is popular, UAC will still be around. Who can say.

All I am saying is that the security model already exists, and if software were made properly, there would be no need (typically) to store programs in the user space. The Medium level process the Standard User has would be no different than LUA was in XP. The difference would be that the software you use should work correctly under LUA and not be so inconvenient. Of course, if you do things that need admin rights all the time, you might be wishing for UAC and its easy prompts. I have a hard time believing they will do away with that entirely. It is just too easy for users who don't know much to use it.

Sul.

 

Yes, that's it. Sorry if I took you in a long run to make you understand, but in the last couple days I have slept only 6 hours, at most. Can't think properly, and that reflects in most of my thinking.

Also, I wanted to meant that Microsoft wants software developers to make their apps write user data to user-space, just as you well mentioned. Sometime ago I read some info about permissions, ACLs, etc., and read something like Admins shouldn't be allowing stuff to be installed to Program Files dir, and I guess I mixed it with this specific matter. Who knows why.

But, I guess that there are a few applications that completely install to user-space. I don't know if that many, but Google Chrome does. We both know how to just take it out of there and place it under Program Files dir. I can even make it install right away to Program Files dir using cmd line with command /systemlevel after the executable name. I haven't done all testing with this command, but setting the user profile is easy using a shortcut. But, I do think that it defined the profile to user-space, if memory still serves me.

But, I can point you to a lot of people who that, if I install them Google Chrome, and then delete the shortcut(s), and tell them to go to Program Files dir to get it, they will. They just won't get far, as they won't find it. They don't know what's user-space, etc. Unless, I tell them, or maybe if they Google for "I can't find Google Chrome", or something like that.

So, I think that the sort of protection provided by Program Files dir, should be extended to user-space... It would prevent malware infecting programs installed to user-space, just like Google Chrome. It would keep the infection out of more restricted areas. Again, I don't know how many more examples are out like Google Chrome, but I guess a few exist.

 

I could see that point. If more and more programs were to install to user space it would be a bit redundant, but as you point out, many users need help as much as possible. I wonder when a beta of the next OS will appear so we can see what really happens. Not that I am in a hurry for it, I am just now getting comfortable with some inner workings of 7.

Sul.

 

@RMUS

Within Windows it is possible to set a deny read (and/or write) for all. SOX & Endpoint practises seem to advert to block ALL client side access to USB etc. This is the reasons user based (token based) protection/allow for USB access will not likely be developed by M$

Marc's presentation said there were Endpoint Securty solutions which allowed on a user bases and allow through encrypted/password protection to directly inject a client with data from an USB stick. So go third party when you need.