Video Screencast Help
Symantec Secure Login will be live on Connect starting February 25. Get the details here.

The Big Vision: Going Totally SVS for Personal Use

Created: 25 Apr 2007 • Updated: 29 Jul 2010 | 8 comments
Language Translations
toralf's picture
0 0 Votes
Login to vote

This article describes a vision I have been following for some months now. As a private user I want to go totally SVS with a secure and sound system. Thus, the target audience is again the users that want to use SVS for personal use on their PC.

The usual dilemma

Generally when Windows XP gets installed on a PC, some user accounts are (at least one is) created during that process. Most private users -- at least in my surroundings -- start using their account right away. Often even without specifying a password for the account. Since the accounts which are set up during installation are granted administrator rights working with them is easy. The user has nothing to worry about -- the system just does what the user wants; no restrictions are applied. Until the system is overloaded with software that was installed to be tested and maybe even uninstalled (which seldom does remove all components and files that came with the software or were created using it). The system gets slower and slower and conflicts occur. And because the system gets huge most private users I know (including myself) don't backup their system let alone the data that got created by them.

And there is the permanent thread to connect to the Internet either by browsing or via e-mail. Since the user has administrative rights all processes inherit the same privileges. A virus or worm or any other thread can dig itself deeply into the system without being noticed or stopped by the user. Even with up-to-date anti-virus and other security software installed the chance to get infested is higher with administrator privileges than without.

No easy solution

Just to remove the user from the administrator group on an existing system does not solve the problem. To install new software or maintain the system the user has to logout and login with a different account that possesses administrator rights. Since this is quite a hassle and sometimes happens in the middle of a different task that shouldn't get interrupted, users quickly revert to the previous privileges.

Additionally, several software products do not work correctly when run with restricted rights, due to restricted access to directories, normal users don't have access to, e.g. the program files directory. Some products even need administrator rights to run at all, e.g. most of Sysinternal products. And it also doesn't solve the problem of the system getting bigger and bigger with each new software product installed.

Even though the user might be removed from the administrator group he might still posses the ownership of several files and directories he created or were created by installing software under his account. This ownership gives this user more rights than a regular user should have.

Only grant privileges when and where needed

The ideal concept is to work with a user that has the minimum necessary privileges and grant individual tasks with just the privileges they need to run correctly. To set up such a system it has to be installed from scratch (I do not know how to convert an existing system, since too many privileges would need to be changed). The system has to have two user accounts both with a specified password. The first account has admin rights and is set up at installation of the OS. The other is the normal user which will be used for all work done on the computer at a daily basis.

Since a normal user isn't allowed to install software and to maintain the system, the idea is to give only the program that needs such administrative privileges these rights for the time it is running, but all other processes are or will be started with the restricted rights. In general there are three situations that need to be handled to grant the necessary privileges:

  1. The program needs to have only once or very rarely administrative rights, e.g. an installation of an application or seldom used system components for maintenance.
  2. The program itself doesn't need administrative privileges itself. It just needs to write data to a directory or registry branch that it doesn't have the rights to do so for.
  3. The application needs absolute administrative rights and is used frequently. Examples for this are the Sysinternals programs, like DebugView, FileMon and RegMon.

For all three situations three different methods exist to handle them:

  1. A free script called MakeMeAdmin by Aaron Margosis grants a process of an application administrator privileges when started. (For this script an improved version exists which was coded by the German magazine c't. Unfortunately the comments in the script are in German.) When started it asks for the password of the administrative account and starts a consol shell with administrator rights. Each process started from this control shell will inherit the administrative rights. The same happens if a program gets dragged onto the script, then instead of a consol shell the application will start directly.
  2. To find out why a program doesn't run with restricted rights its interactions with the system can be monitored with the free Sysinternals tool Process Monitor, which is a modern combination of FileMon and RegMon. The program itself needs administrative rights, so it should be started with the MakeMeAdmin script. It lists all attempts to read and write to the file system and registry. When the list gets filtered for the application in question and for denied or failed actions the file, directory or registry key can be found easily that the application doesn't have enough rights for. If the path can't be redirected inside the program itself (e.g. in its preferences) the rights needs to be changed. But only for that specific file, directory or registry key higher privileges should be granted to the user account so that the application can run correctly. This can be achieved with either the registry editor or the file explorer. Both need to be started with the MakeMeAdmin script.
  3. When an application is used frequently and the handling of the MakeMeAdmin script is already to big of a hassle that program can be granted with administrative rights per se for all future calls. People familiar with UNIX might know the command sudo. Something similar offers BeyondTrusts Privilege Manager. It is a free tool for use in local GPOs and is a snap-in for the group policy editor gedit.msc. It adds the ability to grant specific applications with administrative rights. The application has to be named specifically with its path, or be in a specific path or its hash sum has to be constant. It can also be specified that the all processes started from within this application don't inherited these elevated privileges.

With these three methods a user can work as a restricted user on a PC and maintain the system at the same time. E.g. he can surf the web and download files, work on text documents and receive and write e-mails. For all other purposes he can selectively grant the necessary privileges to a program.

Bloating the system

These methods of cause don't help against the flood of programs that can get installed and not removed properly, or against slow start-up times due to many libraries loaded into memory for programs that are rarely used.

For initial tests of software two software products can be used which shield of the PC of any harm. One is the free SandBoxie, the other software family are virtual machines, see this article of some of its software products. When initial tests are not enough and intensive testing is needed or for all of your other software products even if used intensively or just seldom Altiris Software Virtualization Solution (SVS) should be used. With its layer technique only software currently needed gets loaded into memory and conflicts between software products become a myth. And best of all, if a software product becomes obsolete due to a superior competitive product or due to an update, its layer is quickly and easily removed from the system without leaving a trace. Seldom used software can even get stored in an VSA archive and deployed only when needed and put aside afterwards.

Since a normal user account isn't allowed to create new SVS layer or edit them, the MakeMeAdmin script can be used again to grant the SVS Admin program with the necessary privileges.

Backup strategy

The advantage of the above described scenario is that the system will be divided into three parts of data. One part is the bare OS with some core applications. The second part consists of all the software that is placed in SVS layers. And the third part makes up for the user data files. This separation gives the advantage that all three parts can be backuped independently, which is nearly impossible without SVS.

To backup the three parts of such a system different backup strategies are possible. The main OS with the core applications needs to be backuped only a few times since it is set up quickly from the first backup by applying the latest patches. For these backups a bootable media should exist, from which a previously backuped system can be reapplied to the PC. Since the majority of software products will be in SVS layers these backups should be small and fit on a single DVD.

The software products which are placed in SVS layers can be backuped via VSA archives. A backup after the first customization to the system and then every other month should be sufficient. The only things that might get lost are some custom settings to the software. These should be reapplied fairly easy when the system crashes or the layer gets lost or damaged.

In contrast the data the user creates should be backuped daily, since the work put into this data can hardly be reproduced. Depending on the value of the data even intra-day backups should be performed.


Starting with a freshly installed Windows XP will lead in some cases to a bloated and insecure system if not special precautions are applied. A strategy that will lead to a secure, slim and organized system got illustrated. Best of all, all of this can be achieved for personal use with free software. While the Windows XP internal concepts provided methods to secure the system against threads with too high privileges, SVS prevents the system for getting bloated. Additionally it plays a major role since it secures the virtualized software products against each other and organizes the system into three parts. This organization in turn eases backup strategies.

Comments 8 CommentsJump to latest comment

wilbertnl's picture

I like to evaluate software and I'm involved in beta testing for several software companies.

Your article touches the challenges that I'm facing: Keep the system stable and lean, while continuing with installing 'disposable software'
Disk Imaging software is the start and I have evaluated many disk snapshot solutions. All excellent, but leaving me with an uneasy feeling.
Virtual PC's are an excellent option too.
Nice for making screenshots of boot errors.

SVS 2.1 beta 2 is offered to beta testers and the feature that is catching my interest is relocation of the fslrdr structure.

I imagine a lean system partition with the mandatory software (Security software), a different partition for data and storage and the fslrdr also placed on the data partition.
I can't wait to see how SVS 2.1 beta 2 is holding up when I restore the lean system partition from a disk image and it finds all the SVS layers on the data partition in it's current state.

It should make evaluating conflicting security software a little bit easier, I hope?

I sure hope that Symantec continues with making Altiris SVS 2.1 available for private use.

Misunderstandings are my Expertise

Login to vote
Pascal KOTTE's picture

I receive the confirmation from Symantec the free personal use will keep & still updated. ;-)

I also ususally change the location of the FSLDR to a data partition (D drive), to install "virtually" an application in the standard "c:/program files". The C drive only 10GB with 1 GB free. I install 20GB application "virtually" on the C drive (yes huge one with maps). Very nice: C: drive still have 1GB free. If I select the folder "c:/program files/" & get the "info": The size is well 20GB (all the same on a 10 Gb drive).
Great. I do that on 2003 servers also ;-)

~Pascal @ Do you speak French? Et utilisez Altiris: venez nous rejoindre sur le GUASF

Login to vote
SK's picture

For companies, this can easily be achieved by using our Application Control Solution, which means that all your users are normal domain users and app control elevates the programs that need high rights to run only.

Combine that with our Local Security Solution and SWD, and you are well protected from having users install anything, as the local admin passwords will be randomized preventing them from ever using that way in, and the SW Portal will be there entry point for requesting programs including VSPs.

Connect Etiquette: "Mark as Solution" those posts which resolve your problem, and give a thumbs up to useful comments, articles and downloads.

Login to vote
Scott Jones's picture

Now the article we need is "The Bigger Vision: Going Totally SVS in the Enterprise!"

Scott Jones
Product Manager
Altiris, Inc.

Scott Jones
Business Critical Engineer, Endpoint Virtualization
Symantec Corporation

Login to vote
toralf's picture

Sorry Scott, I can't provide that. But there seem to be several people here at the forum that could help you/us out.


Login to vote
erikw's picture

Going totally SVS? It can be done on a USB stick.

Give every user a U3 USB stick with all the programs, and store the user data on a network.

I can create the USB version with all the rights you want.

A user does not need rights to store a application on a USB stick.

He only needs rights when he/she stores it on the local machine.


Regards Erik Dinamiqs is the home of VirtualStorm (

If your issue has been solved, Please mark it as solved

Login to vote
ItsMeP3's picture

Yes a good idea, all the tools available at our offices but a domain at home just to be secure :-) I think I spend enough of time at work on that.

This does interest me as I am working on a similar idea for my home computer, be organized with all software and have it installed reinstalled at short notice. Then enable software you need for the moment with a click of a button. when finished it disapears with a click as well. I look to have a standardised method of handling storage of favorite software and an automated method of depolying the same without the need of a domain or complicated infrastructure. Have got quite organised in the tools & scripts front but writing the process for the moment has not proceeded anywhere :-)

Check out Microsoft's DropMyRights to run a program when logged in as administrator with less rights for the times you need to have logged in as administrator.

If automated installation for personal use interests you let me know. I do not know whether this is the right place as it deals with software virtulization

Login to vote
Pascal KOTTE's picture

I am also using SVS personal, on XP. My login account is a local "Administrator" like everyone. I love the providing the IE run redirected to a virtual layer.
Main security issue is "running" FireFox or IE, or any other, using an "administrative account". Another quick solution: create a shortcut "runas /user:Guest Iexplore.exe" or similar to never run IE or FireFox using an admin account. All the same you go only on "trusted web sites", they always can be compromise, Good surfs ;-)

~Pascal @ Do you speak French? Et utilisez Altiris: venez nous rejoindre sur le GUASF

Login to vote