Make an existing application always work with UAC virtualization on

Question

I saw several questions that are the opposite of this; "How to disable virtualization?" This is not my question. I want to make the application work with virtualization enabled .

I have an application that works fine under Windows XP, but since it writes its configuration to the working directory (subfolder "C: \ Program Files (x86)"), it does not work fully under Windows 7 If I use the task manager for enabling UAC virtualization, it saves its configuration just fine, but of course it cannot load this configuration.

I do not want it to run as an administrator, since it does not need these privileges. I want to configure it to start with UAC virtualization enabled.

I found a suggestion that I put the magic in the registry on HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AppCompatFlags . For completeness, I also put it in a Wow6432Node , but had no effect.

Answer 1

The file system is virtualized in certain scenarios, as the question arises, how to enable it when your application is not suitable? This is unlikely, MSDN :

Virtualization is not enabled in the following scenarios:

• Virtualization does not apply to applications that are upgraded and run with a full access token to the administrator.

• Virtualization only supports 32-bit applications. Unapproved 64-bit applications simply receive an access denied message when they try to get a handle (unique identifier) ​​for a Windows object. Native 64-bit Windows applications must be compatible with UAC and write data to the correct locations.

• Virtualization is disabled for the application if the application includes an application manifest with the requested runlevel attribute.

Answer 2

it may now come too late, but I am the author of the sentence you found to activate UAC virtualization, and there was an error in my post. The registry keys for the change are as follows:

HKLM\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers\
HKCU\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers\

(pay attention to the "Layers" )

I sincerely regret that you lost a lot of time due to my mistake.

And by the way, let me express my disagreement with Ian Boyd's message. There are places where write rights should not be granted to everyone, for example, this, since this violates the basic security rule "System-wide records should be authorized only for privileged principles." Program files are a system-wide, not an individual user.

All rules, of course, have exceptions, but in this case, you can imagine a malicious configuration file that makes the exec program an arbitrary command as the user that runs it. On the lighter side, it could be assumed that the “error was deleted” by another user, which would lead to the application crashing. Returning to the heavier side, application executable files in Program Files are often run by the administrator sooner or later. Even if you don’t want to, when you delete programs, very often the executable files that are in the Program Files are deleted. Maybe the removal procedure will use this configuration file, which may have consequences if it is created by an attacker.

Of course you can say it sounds paranoid, agreed. I changed some NTL ACLs in NTFS in Program Files during Win XP and was able to sleep after that, but why is there the slightest risk when using the tools?

Answer 3

I found one not-so-well-specified condition in which UAC Virtualization does not work: when the file in Program Files set as read-only .

That is, suppose that the file C:\Program Files\<whatever>\config.ini marked as read-only. When an application tries to change it, UAC Virtualization will return a denial of access instead of re-binding to %LOCALAPPDATA%\VirtualStore\<whatever>\config.ini .

Although I did not find this documented, this behavior is probably performed by design as it makes sense.

The solution is simple: make sure that all files that must be modified by the application are not readable (or simply disable all files, since the user will still not be able to change them).

Answer 4

You have an application, and you want users to be able to modify registry keys or files in places that only administrators can change by default.

If you are using Windows 2000 or Windows XP or Windows Vista or Windows 7 or Windows 8, the solution will be the same:

• provide appropriate permissions for these locations

---

For example, if your program needs to modify files in:

 C:\Program Files\Blizzard\World of Warcraft 

Then the right action to change permissions in the World of Warcraft folder. This is essentially the pad that Microsoft applied to World of Warcraft . (The next time he started, he provided Everyone Full Control to a folder - how else can WoW be updated, no matter which user is logged in.)

If you want users to be able to modify files in one place: you must grant them permission. If you were a standard user trying to run WoW on Windows XP , you will have the same problem - and you need to apply the same solution.

---

Your application writes its configuration to:

 C:\Program Files (x86)\Hyperion Pro\preferences.ini 

then you really do want to give users Full access to this file:

So yours:

• application is not configured to run as administrator
• users cannot modify the executable
• users can modify Configuration.ini

Granting permissions is not so bad; this is how you administer your server.

---

There are two solutions:

• Install on C:\ProgramData\Contoso\Preferences.ini and ACL during installation
• Install in C:\Program Files\Contoso\Preferences.ini and ACL during installation

And if you look at the AppCompat guy's guide at Microsoft:

Where can I write program data instead of program files?

A common distribution of application code is: “my application used to write files to program files. It was as good as any other. I already had the name of my application, and since my users were admins, this worked fine, but now I see that this may not be as good as I once thought, because even administrators work with UAC with standard user privileges most of the time. are my files instead? "

FOLDERID_ProgramData STRONG>

The user will never want to browse here in Explorer, and the settings changed here should affect every user on the machine. The default installation location is% systemdrive% ProgramData, which is a hidden folder when installing Windows Vista. Youll want to create your directory and install the ACLs that you need during installation.

So you have two solutions:

• create the file at installation time and ACL so that all users can modify it at run time
• create the file at installation time and ACL so that all users can modify it at run time

The only difference is semantic. The Program Files folder is for program files . You do not want to store data here.

• And this is not because Diego Queiroz has a sense of security.
• This is because wherever programs go.

Sometimes machines are displayed again and again with the same Program Files . You do not want the data in the machine displayed on your image. This data belongs to ProgramData strong>.

And this is not a security issue.

Some people need to find out where the security border is.