The Big Vision: Going Totally SVS for Personal Use
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:
- 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.
- 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.
- 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:
- 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.
- 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.
- 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.
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.