One of the first screens you will see in the Streaming Profiler wizard is a screen about “Enable User Updates” or in the earlier profilers, this was called “Enhanced security” or “Relaxed security”. Wow! Mysterious terms! The first thing we do in the profiler is hit the admin with a question that they don’t know the answer to. Hum.
- Describe the panels
- Describe what the settings do
- Examples of how this effects application execution
- Guidance on how to configure the setting
Here’s the panel in the streaming profiler version 5.2 (XenApp 5 Feature Pack 2): Hot off the presses, released GA to the web download last night.
Here’s the same panel in the previous streaming profiler (1.3)
What does this setting do?
Under the profiler, it doesn’t do a whole lot. It just sets a BOOLEAN that accompanies the streaming profile. You can see via nice visual form in this streaming profiler, but if you dig down, you’ll find that all this does is set a boolean in the profile XML data; at the PROFILE layer. Changing this setting actually does more work, but I’ll get to that in a minute.
Going back to the Layers of Glass, there are conceptually 3 layers of isolation. Here’s an abbreviated version.
At runtime, the applications in the isolation sandbox see a multi-layer merge of the true machine at the bottom, masked by the installation image and at the top, a per-user layer. The per-user layer is seen “first”, followed by the lower layers of isolation and finally the true disk or true registry of the machine.
The normal action is that the machine starts out pretty much clean, the streaming profiler captures the installation activity of an “installer” that writes stuff to the file system and registry. These are packaged up to become the “blue” layer above, the installation image.
At end user execution, the installation image is laid down on top of the execution machine and as far as the isolated applications are concerned, they are installed. It’s all a lie – they aren’t really installed.
The top layer is initially “clear” or “blank”. As the programs run, they may store documents and similar, but these would generally not be in isolated space, so they don’t really show up in this picture. The application though may WRITE things to “off-limits” locations which would be caught by the isolation system and end up with storage of stuff to the per-user layer of isolation. These land in the top layer of the isolation stack which is set up as one per-user. This is what allows ill-behaved application to run happily under isolation on a multi-user machine when they won’t happily run without isolation. As an example, consider an application that stores settings to the program installation directory in a .INI file. Under isolation, this will be captured and land in per user space and the application becomes runnable in a XenApp Terminal Services world where otherwise it would not work successfully.
Back to this post
If the application updates itself at runtime, the update will land in the per-user layer of isolation and this is bad. Standard procedure when profiling application installations is to TURN OFF all automatic updates. The application should not update itself – this should only be done in the profiling scenario where the administrator commands the update. Recall that the isolation space is ONE and the per-user space are MANY, so we only want application content to be updated in a single place.
What does “Enable User Updates” do?
If the user downloads application updates such as .DLL updates or .EXE updates, should this be permitted?
The general answer is “NO!”. Some administrators may have a scenario where this is desired. The common ones are users wishing to install their own plugins for isolated web browsers or install their own addons for things like Microsoft Office.
How does it work?
Put your file system filter driver writer hat on. For isolated applications, EVERY TIME the application opens a file or tries to open a file, you get first look. If the file open is for executable content, should this be permitted? If “enable user updates” is “off”, then file opens for RUNNING executable content from the user layer will be denied.
The neat part here is that the isolation system distinguishes this behavior based on WHO the caller is.
If the caller is vanilla application wanting to read or write content, no problem – do what you want. If the caller is the Windows LOADER, then this setting comes into play. If the LOADER is trying to load executable content from the per-user layer of isolation, then the isolation system can be told to FAIL that operation, and this is what this setting controls. Pretty neato.
The setting while stored as a profile level single property (a boolean) is implemented in the isolation system as an attribute of EACH of the isolation rules for EACH execution target of the profile. If you set the profile level property, the streaming profiler must modify the isolation rules (many) for each Target of the profile. This means that if you have a profile with 4 execution targets and you’re editing one of them – and you set the profile level property, behind the scenes, the profiler brings the other 3 execution targets into “edit state” to make the change and will eventually write all 4 targets back to the application hub. Going to edit state to change the rules requires unzip of the can file from the network server onto the profiler machine. If the profile/targets are large, this can be a very painful operation to accomplish a single boolean set, but this is how it is. If you make this change, be aware of the large behind the scenes work that the profiler is doing. Grummble yell a bit and then it will be done.
Fun with streaming – Great entertainment in isolation circles
Turn on the -x RadeRunSwitch so you can an isolated command prompt when you launch your next favorite streamed application. This assumes you have user updates disabled, which is the default.
< it runs >
< see textual giberish – the file open succeeded for read access from CMD.exe >
c:\Windows\System32>copy notepad.exe n.exe
1 file(s) copied.
< file copy was successful – n.exe is at the per-user layer of isolation >
< see textual giberish – the file open succeeded for read access from CMD.exe >
The system cannot find the file c:\Windows\System32\n.exe.
The isolation system LIED to the Windows Loader – returning ERROR_FILE_NOT_FOUND (2) rather than completing the loaders request to run this file from user layer of isolation. This is what this setting does!
But wait, there’s more!
c:\Windows\System32>copy n.exe notepad.exe
1 file(s) copied.
< it runs!! >
Why does notepad.exe succeed in the final case? Easy, there are two notepad.exes. At the per-user layer, there’s a notepad.exe which was written on the file copy from n.exe. We don’t care what this file is, but it is executable content and it exists at the per-user layer of isolation and therefore it doesn’t exist for purposes of running programs.
Since the “Enable user updates” setting is set to disable user updates, executable content at the per-user layer of isolation does not exist from the perspective of the Windows loader. BUT – at the physical layer, there does exist a file with that name and this can satisfy the file open, without violating the isolation rules. There could also be a file with that name at the application installation image layer. In this example there wasn’t, but there could be. The isolation system starts at the top and goes down until it finds a hit. If “Enhanced security” is enabled, then the per-user layer is “off-limits” for execution of executable content.
The grand result
The application “update” applied by the user may have been applied as far as the user or application is concerned, but in reality, it was not applied. The version of the application that is running is the version that the administrator profiled. Pretty cool stuff.
Why did we rename the setting?
Putting “security” in the title implies that this will somehow prevent users from doing things to run content that they download and this is not what it does. If the program updates itself, then this setting will block that content from being executed. The setting can also block user installed additions to the program (plugins), depending on the location to which they were installed – was it included as an isolation rule during profiling?
Take a web browser for example, if the user downloads executable updates to the browser, this will be captured and the user installed stuff won’t run, but if the user downloads evil.exe and places it on their desktop, and then double clicks it – this will be outside of isolation so the layers here do not apply. This is also true if the user downloads evil stuff to locations outside of isolation and launches it from the isolated application. It will still run isolated, but it will run! Describing this activity as “disable user updates” is more accurate than the previous words, so we’ve made the change. I also hope that it removes confusion in the streaming profiler wizard. “Enable user updates” is pretty easy to understand.
How should you create your profiles
1) Enable user updates should generally be “off”. Plugins are a rare need and where there is a real need for users to add plugins, start asking yourself if you can add those plugins at profiling to the common layer. OR, if the use of user installed executable content is large, should this application be locally installed rather than isolated?
2) Always tell the application to NEVER update itself at runtime.
A look to the future
Streaming dev team are discussing removing this option from a future release. That is, “Enable user updates” will always be OFF. I’m not sure of all the ramifications of this yet. The question really is “how many admins are profiling their applications with user installed updates permitted”? I hope the number is “few”.
Product Architect – Application Streaming