Enabling (service) process access to App-V virtual environment

Back in the last November, Sebastian Gernert who works as a Microsoft’s Support Escalation Engineer wrote an article about fixing Volume Shadow Copy –related issue with the App-V Client in the German App-V blog (browse the site with Chrome and you get handy translation prompt if you don’t read German).

While the actual issue itself as outlined in the article is not terribly interesting unless you happen to do backups on your Windows 7 machine with VSS enabled and are concerned with such error condition, the most interesting tidbit found in the article concerns of one specific registry key of the App-V Client.

ServiceInclusions key

As Sebastian instructs, you can add to the HKLM\SOFTWARE\Wow6432Node\Microsoft\SoftGrid\4.5\Client\AppFS\ServiceInclusions –key a new string registry value “VSS”, with the value data of “swprv”. In the case of 64-bit Windows, that key is naturally in the 32-bit registry side so additional Wow6432Node applies to the path.

As one would expect, no further explanation or discussion is provided about this key or the meaning of the value that had to be entered to make VSS to play along with App-V. And, of course, Microsoft has not been documenting this particular registry key in the official documentation either. So what does it do?

Now, if you are smart and remember what has been said earlier (around 4.5 timeframe) about App-V Client granting a special access to certain processes to VE, and you can read between the lines of the Sebastian’s post and you are able to deduct information from the name of the key itself as well as the value data – the meaning of this key becomes pretty clear: its purpose is to allow certain Windows Service processes into App-V’s file system (aka. the Q: drive)!

To examine the thing further, I took a look at the machine with 4.6 SP1 Client installed and there’s already a couple of entries pre-populated for that key:

The text data for the values suspiciously looks like service names, so after little bit of browsing through the services currently installed on the machine both of the listed services can be identified.

One of the entries is for a service called “Application Identity”, which has something to do with correct functioning of AppLocker –feature and which has an internal service name of “AppIDSvc” (matching the data in the value):

Another entry from the key matches “Microsoft Antimalware Service”, which is the Security Essentials/Forefront Client’s service and which has an internal service name of “MsMpSvc”:

Makes sense; App-V Client allows both AppLocker and AV an access to the virtual drive so that they can see all applications over there. In a way, this also makes the part of the explanation of “certain privileged processes” more transparent as you can actually see what gets the special treatment. The reason I say it’s only partially transparent is that there’s still some other processes (like, I think, lsass.exe and winlogon.exe) that doesn’t get listed in the key but still has the access to all virtual environments and/or virtual drive.

But does this mean that we could actually grant the same access to any process of our own?

Access to virtual drive for any service process

As the name of the key implies, the system is designed to allow access for the Windows service process executable and not just any random process running in the system, so adding new entries for things like cmd.exe will not fly.

For the purpose of testing a service process access using the ServiceInclusions -key, we would then need to have our own custom Windows service that tries to take a look at the Q: drive. Fortunately it’s very easy to create service executable with C# (there’s pre-built template project for it in Visual Studio as well) and as such, here’s a complete listing for it (Service1.cs, sorry if the code looks bad as I couldn’t figure out how to format it nicely):

using System;
using System.Collections.Generic;
using System.ComponentModel;
using System.Data;
using System.Diagnostics;
using System.IO;
using System.ServiceProcess;
using System.Text;

namespace ServiceTest {

public partial class Service1 : ServiceBase
{

public Service1()
{

InitializeComponent();

}

protected override void OnStart(string[] args)
{

try
{

string[] dirs = Directory.GetDirectories(@”q:\”); foreach (string directory in dirs)
{

File.AppendAllText(@”c:\temp\appvdirlist.txt”, directory + Environment.NewLine);

}

}

catch
{

File.AppendAllText(@”c:\temp\appvdirlist.txt”, “No access to Q” + Environment.NewLine);

}

}

protected override void OnStop() { }

}

}

This test service generates executable only 7KB in size, and it has been designed to dump list of directories in the root of the Q: drive to text file in c:\temp, and to handle possible error in enumeration, when it starts up. Nothing more, nothing less.

Now that we have our compiled executable, let’s install it to the system as service. For the purpose we can use excellent sc.exe which ships with Windows (sc create “ServiceName” binPath= “PathToExecutable”), running with elevated privileges of course:

We now have an interestingly named service called “QDriveTest” in our Services –applet, which we can start and examine whether or not we get anything in the c:\temp\appvdirlist.txt file:

Sure enough, the text file is created and looking inside it shows that (as expected) our service does not have an access to the virtual drive:

As our purpose is to enable that access, let’s stop the service, remove the text file and make some modifications into our registry key. Remembering the naming format of that VSS key, we add a new string-type value into ServiceInclusions –key under AppFS –key and give freeform name for it. The important part is the value data, since that has to match our service’s name (“QDriveTest” in this case):

Since the setting we are modifying applies to the filesystem part of the App-V Client, we need to restart App-V Client’s own service (“Application Virtualization Client”) to make changes to take effect. After restart (remember that if you have virtual applications running, restarting this service makes them to disappear immediately!), we can start again our own service. And what is it that will be written to the log file now…?

It’s success, that’s what it is! My test service was able to go to the Q: drive and list my (modest) list of virtual application packages mounted over there. I didn’t bother to test it, but I’m 100% sure it could have been possible to go into each of those directories and see and access all of the package files from my service’s code.

—

What this post demonstrated is that it is possible to have access to App-V’s virtual drive, if you are creating software that installs a Windows service. Naturally as long as you add that service of yours into App-V Client’s registry entries so it knows to allow access to it.

Btw, it’s worth noting that the registry key discussed exists only beginning of 4.6 RTM Client, so 4.5 and older clients do not have this key or are able to use it even if created to the registry manually.