Software Virtualization Solution Security

The SVS development team went to great lengths (and spent a few long weekends) to ensure that system security was not compromised by installing or running SVS. This article explains the security behind the product.

Authors:
Jeremy Hurren
Craig Walker

Software Virtualization Solution uses the security systems that are built into the Windows NT family of operating systems. Access to Software Virtualization Solution is controlled by Access Control Lists (ACLs) in the registry and file system. The ability to protect files and directories through ACLs requires the use of the NTFS file system. ACLs on virtualized items (registry entries, files, and services) are persisted normally and Software Virtualization Solution moves the ACLs when a Virtual Software Package (VSP) is exported and imported. This section explains how SVS handles rights on virtual files, and the on-disk structure of a VSP. It also explains how to make sure that anti-virus, inventory, and other programs function correctly in the virtualized environment.

Rights necessary to administer Software Virtualization Solution

In order for a user to manipulate Software Virtualization Solution or VSP data through SVS Admin, that user must be a member of the local Administrators group. There are two exceptions: the rights to activate and deactivate can be delegated. Users that have Read access to a key named HKLM\System\Altiris\FSL\Rights\Activate are able to activate VSPs through SVSCMD or SVS Admin. Users that have Read access to a key named HKLM\System\Altiris\FSL\Rights\Deactivate are able to deactivate VSPs through SVSCMD or SVS Admin. Users that have rights to change the permissions on these keys are able to modify these privileges for other users.

While SVS Admin requires a user to be an administrator in order to modify VSP data, the user may still be able to browse directly into the Software Virtualization Solution redirection areas and modify files and registry keys. The user will have the same rights to the files and registry keys in the redirection areas as if the application had been installed normally, so this is not a problem if the application properly creates ACLs for its files during install.

Anti-virus products and inventory products

Software Virtualization Solution does not affect the run-time protection feature of anti-virus software. Anti-virus products properly scan virtualized files when they are opened. Any measures that the anti-virus product takes against a file that it thinks is infected really happen and are not virtualized.

However, there is an issue with manual anti-virus scanning. If multiple files exist in the base and in one or more VSPs and these overlay each other, the scanner only sees and scans one of the files. For example, it might enumerate a file named C:\TEST.TXT and scan it, but what it does not see is that a VSP may have another version of the same named file.

For this reason, we recommend that anti-virus scanner programs be configured to be "ignored" by the SVS system. This means that when the scanner programs run, they will not see any virtualized files; they will only see the file system as it really exists. This guarantees that all files are properly scanned. The list of ignored executables can be modified by adding or removing strings to HKLM\System\Altiris\FSL\ProgramIgnoreList which is a MULTI-SZ value. The paths can be hard-coded (c:\windows\scan.exe) or variablized ([_B_]WINDIR[_E_]\scan.exe). If you have other programs, like an inventory product, that you wish to have view the file system data without any virtualization, you can add them to this list. You must restart in order for these to be in affect.

VSP User Specific Areas

Data layers and the Writeable sublayer of Application layers are user specific. This means that the layer has a unique area for each user that holds information that is unique to each user. In the advanced editor in SVS Admin on the File tab, you can see that these layers contain some areas that are common for all users, like the Windows directory, but areas that are unique for each user exist under a SID directory. The directory is named with a string representation of the user's SID. This directory contains directories like the user's profile directory and desktop directory. A corresponding area exists in the registry. Under HU (HKEY_USERS) you will see a SID directory for each user. At runtime, this maps to HKEY_CURRENT_USER.

The Read-only sublayer of an Application layer does not contain unique entries for each user. It contains only one copy of user data that is contained in a section called USER_TEMPLATE. During the capture process, any user specific data goes into this area. When the layer is first used by any user outside of capture mode, a SID directory is created for the current user and the contents of the USER_TEMPLATE area are copied. The USER_TEMPLATE area in the Read-only sublayer is not used during normal operation.

Files, directories, and registry keys are protected with the same rights that protect the corresponding objects in the base. Example: When the DESKTOP folder is created in the layer, the ACLs are copied from the user's base DESKTOP folder. This assures that only the proper users have rights to this folder.

The FAT file system is not secure. It does not support the protecting of files and directories with rights. When you build layers that you plan to use on a computer that is using an NTFS file system, you must build the layer on a computer that is using the NTFS file system. If you build a layer on a computer that is using the FAT file system, no rights will be used and when the layer is moved to a computer that is using the NTFS file system, all files and directories will simply get default rights.

When a layer is exported, the rights that are contained in the file system are represented in a file called "acls" in SDDL format. At import time, after the files and directories have been extracted, this information is used to re-apply the proper rights.

Rights to services are handled in a similar fashion. An SDDL string is generated and used to maintain the proper rights on the service.

Hiding the FSLRDR Redirect Locations

The SVS File System Filter driver has the ability to actively hide the fslrdr redirect locations in the registry and the file system. These areas are already protected with ACLs so that, by default, limited rights users are not able to enter these areas. Causing the driver to actively hide these areas has the advantage that the locations are not visible to anyone even if the system is configured to show hidden files. The disadvantage of using this is that programs that traverse the entire file system looking for data (Example: anti-virus scanners and inventory programs) will not see these areas either.

Note

Enabling this does not affect run-time virus checking. To enable the active hiding of the redirect locations by the driver, create a value called "HideRedirectAreas" of type DWORD under HKLM\SYSTEM\Altiris\FSL. Set the value to "1". A restart is required to put into effect any changes to this value.

Launching of Startup Items

The information in this section does not apply when a layer is activated at start time because it is marked to be active on start. This only applies when a layer is manually activated.

When a layer is activated, Software Virtualization Solution typically launches all of the items in the layer that are configured to run at startup. This includes entries in the startup folder, the common startup folder, run entries, and run-once entries. The launching of these programs happens in the context of the user that activates the layer. This is a potential security concern. Example: When a layer is activated remotely by Notification Server, this happens in the SYSTEM context by default. Because of this, Software Virtualization Solution will not launch these items unless the activation is being done by the interactive user who is logged on to the system.

This does not apply to the OnEvent actions. OnEvent actions are run regardless of how the layer is activated. Care must be taken to ensure that actions configured to run in these scenarios are secure and cannot be exploited by any users on the system.