Software Virtualization (Thinstall/Altiris SVS)

Mr

Peter,

It sounds like you got a decent idea of how to setup conflicting software on one system with SVS, so that you switch between them like you switch cable channels.

I'm still trying to understand how to manage the data that is produced in these layers.
I created a layer containing Free Download Manager and now I watch downloaded files disappear/reappear at deactivate/activate of the layer.

Another example:
I downloaded feedreader.sva and installed the layer.
In the activated layer I checked for updates, and bookmarked the page with release information.
After I deactivate the layer, that bookmark is gone.

 

Re: Thinstall - Anyone try it?

Hey wilbertnl,

cthorpe helped me with this issue before and now I shall pass on the knowledge to you

If you want the downloaded files to "stick" (get written to the base), you must exclude your download directory.

If you go into SVSAdmin and doubleclick the layer it will bring you to the advanced options. From there go to excluded entries (tab). There you can right click the empty space and select "create new" or something like that and add directories that when written to by the software will be sent to the base and not redirected to the layer.

You can also exclude only certain filetypes if you'd prefer, but in my opinion it is better to just exclude one directory that the files are allowed to be permanently written to. (Unless it's possilbe to do both, I'll test it later)

Another way is to download the files and then move the files with explorer to another folder. This is because since explorer is part of the base, anything it writes is written to the base as well.

 

Re: Thinstall - Anyone try it?

Wilbertnl,

Think about the excluded directories like anchored folders in ISR.

Try excluding the bookmark.html, favorites folder, etc that your browser uses.

C

 

Re: Thinstall - Anyone try it?

Thank you both of you suave and cthorpe.

I notice the behaviour of data that is created in an application layer, and I'm not sure yet what suits me best.
Although I have a structure of download folders, sometimes I pick a different location, like the desktop.

And like in the example of feedreader, that checks for updates and opens a browser, one would not think that a bookmark/favourite created in that browser session ends up in the layer... No user is prepared for that with exclusions.

What I try to say is: SVS is really powerful and the user needs to understand the concept and behaviour of executable and data really well.
No matter how well prepared the sva or layer is.

I'm mostly just giving my observations sound here.

 

Re: Thinstall - Anyone try it?

I think the issue is that the browser may be a child process of the feedreader process. If that's the case, then I think any actions by the browser are redirected to the layer. If you launched the browser on it's own while the feedreader layer was active, then the browser would be able to write to the base filesystem.

 

Re: Thinstall - Anyone try it?

You are correct with that, cthorpe.
I could easily open another browser and copy the URL. The SVS user needs to understand the impact of the layers.

 

Re: Thinstall - Anyone try it?

Yeah I agree with both of you, it is powerful. Here is what I have realized so far:

If you open a layered application, anything that application writes/modifies stays within its layer. Furthermore, any changes made by opening an application that was written to a layer by a layered application, stays within that layer as well.

So what you need to keep in mind is that if it is in the layer, it stays in the layer (no matter how it got there).

Here is an example to illustrate this:

You have a layered firefox that you activate and open firefox from. You browse the web and download some software you wish to install (lets say, PhotoFiltre for example). So you download pf-setup-en.exe from photofiltre.com with your layered firefox. Since firefox is the process that is writing pf-setup-en.exe, that file gets redirected to the firefox layer and becomes a part of it.

Now lets say you launch pf-setup-en.exe in order to install it. Since pf-setup-en.exe is already a part of your firefox layer, any changes it makes to the system get redirected and stay within the firefox layer. So after you install it, and deactivate your firefox layer, photofiltre will be gone as well. When you reactivate the firefox layer, you will see that photofiltre appears to be installed again. Furthermore, if you open photofiltre and draw some picture and save it, that picture will also be redirected to the firfox layer (because the process that created the picture photofiltre.exe is a part of the firefox layer which means it can only write to the firefox layer)

Now here is the tricky part. Lets say when you downloaded the photofiltre setup it came in a zip file. Lets call it pfsetup.zip. So after you download pfsetup.zip, the zip file becomes a part of your firefox layer. So now you extract pfsetup.zip to get pf-setup-en.exe. This time pf-setup-en.exe is NOT a part of the firefox layer. This is because when you extract the zip file, the process that creates pf-setup-en.exe is now your archiver application (Winzip, Winrar, 7Zip, etc..)

So pf-setup-en.exe becomes a part of whatever your archiver is installed in. If your archiver is installed in the base, then pf-setup-en.exe is written to the base and any changes it makes when you launch it are written to the base. If you have your archiver in its own layer, then pf-setup-en.exe is written to that layer and any changes it makes when you launch it are written to that layer.

It gets confusing, but with proper exclusions this can all be taken care of. I agree it is important to understand how ASVS works before actually using it in a real system. That's why I am playing around with it for now on my test machine while I learn

-

In addition to all that, what cthorpe pointed out is that any changes made by a process that is launched by a layered application will be redirected to that layer as well. I will test this out. I am pretty sure he is correct about that though.

Edit: Yep, seems like wilbertnl has confirmed this in the post right above this one

 

Re: Thinstall - Anyone try it?

Excellent examples, suave!
Thank you.

 

Re: Thinstall - Anyone try it?

Cool!

And I just had another thought right now. If what cthorpe says is true, then this might mean we can use ASVS as a temporary sandbox to run untrusted programs randomly without creating layers for them.

Here are my thoughts, what if you create a layer for cmd.exe. Nothing else, just cmd.exe.

Then when you activate this cmd.exe layer and launch cmd.exe from it, any system changes made by a child process of the layered cmd.exe will be redirected to the cmd.exe layer.

So you can easily launch and test software, or run untrusted programs in a virtualized environment. Reset your cmd.exe layer and all changes are rolled back.

I will test this out as well when I have time! I hope it works!

 

Re: Thinstall - Anyone try it?

Thank you Suave and Sukarof for your answers ;-)

Also, is there an email from someone at Altiris to who we can ask questions and also a Tutorial of Altiris SVS?

Thanks,
Atomas31

 

Re: Thinstall - Anyone try it?

There is a whole living community: http://juice.altiris.com/svs
Forum: http://forums.altiris.com/
Knowlegde base: http://kb.altiris.com/

 

Re: Thinstall - Anyone try it?

btw, I had a chance to test out my theory (2 posts above) and it worked!

So just incase anyone is interested, here is what you need to do in order to make your own on-demand virtualizer built into ASVS:

1) Open up notepad.

2) Type: xcopy C:\Windows\system32\cmd.exe "C:\Program Files\VirtualCMD\"
*NOTE* You can replace C:\Program Files\VirtualCMD\ with whatever folder you want to install the virtual cmd.exe file to.

3) Save the file as vcmd.bat

4) Open SVSAdmin and create a new installation capture. Call it VirtualCMD (or anything you want really)

5) You need to select the vcmd.bat file that you created.
*NOTE* SVSAdmin only allows you to select exe/msi files. That's ok, just type the location to vcmd.bat manually.

6) Start the capture. SVSAdmin should launch vcmd.bat and save the newly created cmd.exe as a layer.
*NOTE* This step should only take like one second to complete.

7) You are done.

Now you can activate/deactivate the layer at will.

When the layer is active, you can load up C:\Program Files\VirtualCMD\cmd.exe (or where ever you installed it to in step 2)

Any changes made to the filesystem/registry by anything you run from this virtual cmd.exe will be redirected into your VirtualCMD layer.

Reset the layer and all changes are gone.

Now you can use ASVS as a sort of "on-demand virtualizer" that will allow you to test software installations and run untrusted programs in a way that wont make any permanent changes to your system without the hassle of having to create new layer every time

Pretty cool

 

Re: Thinstall - Anyone try it?

What about using one of the GUIs available at Atiris Juice instead of cmd.exe?

http://juice.altiris.com/download/165/program-launcher

That might make it easier to do whatever you want in the quick virtual layer.

 

Re: Thinstall - Anyone try it?

Yep it will definitely work with the program launcher as well. It's a matter of preference really

 

Re: Thinstall - Anyone try it?

The title of this thread really needs to be updated.

 

Re: Thinstall - Anyone try it?

Indeed, I'll bet there's some people that would be interested in Altiris that are missing out

 

Re: Thinstall - Anyone try it?

I asked for the title to be changed to "Software Virtualization" over > here <

So maybe when the Mods have some free time they will do it for us

 

Re: Thinstall - Anyone try it?

Re :Altiris Software Virtualization Admin.
You may like to try this ? (A Temp Layer)
Open the Altiris Software Virtualization Admin window
select file>create new layer.
then select Data layer. hit next
select Directory then browse & select drive "c" hit next.
then finish.
Now activate this layer.
good now you can add apps surf the net & what ever files
are added or changed on drive "c" will vanish when you
deactivate this layer. coooool.

 

Re: Thinstall - Anyone try it?

Maybe you find some info about rebooting installations here: Application Best Practices
Search for reboot.

And this: Virtualizing Applications that Require a Reboot During Install

 

Re: Thinstall - Anyone try it?

I was thinking the exact same thing yesterday, but haven't gotten around to testing it out.

But now that I think about it, I don't believe you would need to set it to auto-activate. The reason is simply because, there would be no difference if you auto-activate it or manually activate it. The same thing would happen upon activation no matter when you activate it.

So with a "reboot required installation" I would just reboot the PC, then activate the layer manually and save the changes. You could set it to auto-activate if you wanted to, but the more important thing to do would be to save the changes.

 

Re: Thinstall - Anyone try it?

If it is an install that at the end tells you that you need to reboot, but doesn't force you to do it right then, just deactivate the layer then reactivate it. When you reactivate it, it should perform whatever tasks would be done after a real reboot.

C

 

Re: Thinstall - Anyone try it?

I'll admit, at first this sounded to me like a cool thing to do but believe me it's not. I just tested that out and I wouldn't recommend doing it at all for the following reasons:

1) It only redirects data written to the filesystem (not the registry). So upon deactivation only the new/modified files will be cleared, but your registry will be a mess.

2) Any files that are modified get removed from the base and placed in the layer. So if you update any software or something you run modifies any critical system files, those files will be gone after you deactivate the layer! Huge problems will result.

Eventually, you will inadvertently corrupt the software on your PC as well as your OS and registry!