App Volumes | Lack of App Verification

So after being introduced to App Volumes at PEX I thought it was absolutely amazing. I was finally released from the Thinapp hell that I was oh so accustomed to on a regular basis. After talking to each of the people in the panel I started to think of some things that should be implemented in the product that aren’t.

First off we need to understand the actual underlying framework for the product. App Volumes are client server based from everything that I have seen. You have to install the agent within the guest OS that you are either creating the App Stack on or provisioning the App Stack to and that agent checks in to the App Volumes Manager. Pretty simple right? This is what the overall architecture is from an extremely high level.

Applications are either provisioned to machine accounts or user accounts so application assignments or streaming really isn’t an issue with floating desktops. I think this is awesome except that there is just a vmdk attached to the VM in question when it is either powered on or the user logs in. This vmdk contains all of the applications that you installed during the provisioning process.

So let’s walk through what happens when we provision applications to an AppStack.

The initial notification will display since I am in provisioning mode on USER-VM$

11

I will now go ahead and install the vSphere 5.5 C# Client in the App Stack

1

Once the install is complete we go ahead and click OK

11

Now we need to reboot the machine to complete the install

1234

And prior to completing the install I will check the md5 for the executable that we are going to replace

12345

 

So that was rather easy but now we are going to find the app volumes .vmdk file that is stored on my lab’s VMFS datastore. This is somewhat easy because most people are going to keep the default path of /vmfs/volumes/datastore/cloudvolumes/apps/yourappstack.vmdk

Let’s attach the AppStack vmdk to my AD server. This can be any server in the environment and the user only needs rights to the VM and the datastore that the vmdk is stored on. This server does not have the App Volumes agent installed in the guest OS and only is running VMware tools.  The only way that this works is if you are able to mount the disk when it is not being used or assigned / mounted. This is the only instance where I can do this.

After attaching the disk open disk management in the guest

12

Next we need to online the disk

13

 

However once we explore the disk we don’t see our applications in the root. So if we open Powershell or Command Prompt and do a dir and a dir -h we see the following

14

 

Once we actually use Explorer we can change to the SVROOT directory and that will contain all of our files and we can just navigate and replace as needed. Here is the new MD5 of the VpxClient that I wrote opposed to the original

1234

1231245

4d6d6c8782473057df8ac6d471a8af1b4a1e625963b8c7d5a7a8a030cefecc53

Now we just remove the AppStack vmdk from the VM we are using to change the data

So now what? Well we remove the disk and then once the App Stack is provisioned or used we see the following as our user who has the assigned application.

22

 

If we check the folder location and based on my previous screen shots I never changed the icon. The App Stack apparently just keeps the original icon even though the underling publisher / application has changed. This can be seen here.

23

So the application that I wrote just pings the default gateway as seen here.

1222222

How likely is this? Not very. The thing is, is that you only need basic login, vm, and datastore rights to do this. The hard part would be knowing when a stack is created or being rotated out. So I don’t think it’s a huge problem or an immediate threat BUT it shows a good reason to put it in a future release.

Remember how I said there is a client / server architecture in place for App Volumes in the beginning? Well at this point it has absolutely NO idea that the underlying files have been changed in an App Stack that is read only. If there was a procedure that was done after an App Stack was created which calculated the hashes on all the files on a non modifiable disk then this wouldn’t be a problem. I have no idea how hard it would be to implement but I have brought it up and I haven’t heard anything back.

Despite all of this I think it’s a great product and I think as the product matures things like this will be incorporated into the client server architecture.