|
Posted by ~BD~ on September 24, 2008, 2:12 am
If you were Registered and logged in, you could reply and use other advanced thread options
> NOTE: The following newsgroups were REMOVED from my reply because
> software virtualization has nothing to do with security or virus
> prevention: microsoft.public.security,
> microsoft.public.security.virus.
As it is a matter of opinion, Vanguard, I have now ADDED your reply!
Dave
> SVS (Software Virtualization
> Solution) will not increase your security. It will not prevent viral
> infection or its deleterious effects. SVS will not do either anymore
> than doing backups will. That is not what SVS is about at all. While
> it is very, very difficult to punch out of a virtual machine, programs
> that run when a virtual layer is active have just as much access to your
> host as if they were running outside a layer and in your base host.
>
> Software virtualization. It's been around for awhile but end users
> don't know much about it. A free version can be had at
> svsdownloads.com. Altiris had their SVS product which Symantec bought.
> Now Symantec is working with HP, Dell, and Intel of providing VPS
> which are pre-packaged virtualized products; i.e., you can add a VPS to
> add a virtualized product. This isn't the same as running a virtual
> machine. The virtualized software runs in its own layer but within
> your host rather than in a guest OS.
>
> I've been using Altiris SVS for a very short time. It works but has
> some bugs. For example, when I activate a layer, I can no longer
> shutdown/restart my host using the Start menu because the shutdown
> dialog disappears in a second. The personal version doesn't let you
> run layers mutually exclusive of each other. That is, if you have
> multiple versions of a product that you want to test and because all
> cannot be currently active on the same host at the same time, you can
> manually select one layer to activate for one version but have to
> remember not to activate the layers for other versions. It would be
> much easier if you could place conditions in a layer that it not load
> when certain other layers are active or to force specific other layers
> to deactivate when you activate the one that you want. The business
> version might have this. You could simulate this conditional loading
> by using a batch file or script and use the command-line version of
> their SVS program.
>
> There are lots of VPS packages already available, include web browsers.
> The 2 main sites that I visit at juice.altiris.com and
> svsdownload.com. While there are forums at juice.altiris.com, they
> tend to be visited by network admins and developers so they are way
> above the level for common user questions. Instead go visit the
> altiris forums (forums.altiris.com) under the software virtualization
> group.
>
> For corporations, this makes a lot of sense because they can easily
> track how many licenses of a product have been assigned to users. They
> can see who is using what product.
>
> It's not a panacea. Any application that loads a driver won't work
> with software virtualization unless you manage to get the driver out of
> the layer and load it in the base host. The driver has to be there
> before you load the driver. The layer will not register and load the
> driver (unless it is a dynamically loaded driver). I've got some games
> within a layer for each one and they run but not all games will work
> inside a virtualization layer. One user noted that Halo won't work (I
> think Steam was also mentioned) because their copy protection is too
> strong and won't let the game work when virtualized.
>
> Virtualized is somewhat of a stretch for this technology. You are
> actually using a kernel-mode file redirection driver to hide files when
> the layer is deactivated. Registry entries are similarly hidden. So
> the program really is running in your base OS but all its file and
> registry entries can be hidden when its layer is deactivated and they
> reappear when you activate its layer. As it stands now, it isn't a
> perfect solution and still needs a lot of work. In a corporate
> environment where hardware and software can be enforced and controlled,
> it works well. In the public venue, and considering the level of
> expertise to figure out how to make it work, it can be a disaster. It
> took me a whole day to figure out how to move the Start menu group
> added by a game install so it was somewhere else in my Start menu (you
> have to modify by editing the layer's properties rather than moving the
> Start menu group around). There are also read-only and writable
> sublayers within a layer where sometimes you have to move a file, like
> an .ini file, out of the read-only sublayer into the writable sublayer
> so any changes to it will survive if you reset the layer. Resetting
> the layer is one of the advantages (if done right) of virtualization.
> It lets you revert that layer back to a base state. If you, malware,
> or corruption end up screwing over or deleting a file, you can reset
> the layer back to that base state and you're good to go. Hopefully you
> configured your data so it was stored outside the layer or in the
> writeable sublayer; else, when you reset the layer, you would lose all
> your data. Tech problems are easier when all you have to do is to
> remotely reset a user's layer on their host and its back to the fresh
> install state.
>
> If you actually bother to look and use SVS, you'll see that it does
> nothing to eliminate the need for expertise in using it, in installing
> or deploying applications, or in fixing problems (that reverting to the
> base state for a layer doesn't fix). It is NOT protection against
> malware. When a layer is active, the malware within it still has the
> same access to your devices and files that it would have when not
> running virtualized. So far, I've used it for a couple games because I
> know that type of software NEVER cleanly uninstalls. In fact, if you
> install an app within a virtual layer, you won't see a Remove button in
> the Add/Remove Programs applet for that program. It's listed but you
> remove it by deleting the layer, not by running its uninstall program.
>
> I would NOT recommend to use SVS for trialing unknown software (or any
> software that you're not sure if you want on your host). I use a
> virtual machine for that. Once the layer is active, that trial program
> has full access to your host just like it does when not virtualized. A
> VM keeps the scope of effect by a trial app within the VM, and I can
> revert to a baseline snapshot for the VM to completely get rid of the
> trialed app (don't even have to bother uninstalling it).
>
> SVS has advantages. It also has disadvantages. And the personal
> edition that you get to use still has some flaws or deficiencies. What
> Symantec delivers to Dell, HP, and Intel is not what you get to use for
> free. Users that implement SVS will end up making MORE work available
> for Lipman and Bear, not less. It will probably helpdesks to some
> extent but I, as a user, know that getting my layer reset to its base
> state means I could lose the time I spent to tweak that application and
> possibly some data if the layer wasn't setup correctly (and most end
> users won't edit the properties of their layer to set it up correctly
> and instead just use the defaults which may not work as wanted).
>
> If you want to know more about software virtualization, go visit their
> web pages and read.
>
> http://www.altiris.com (redirects to a Symantec page)
> http://juice.altiris.com http://www.svsdownloads.com
> http://forums.altiris.com (Software Virtualization Solution)
>
| 
XML site map