How the Workspace Virtualization Agent affects security

Article:HOWTO50183  |  Created: 2011-04-18  |  Updated: 2011-09-26  |  Article URL http://www.symantec.com/docs/HOWTO50183
Article Type
How To


Subject


How the Workspace Virtualization Agent affects security

The Workspace Virtualization Agent uses the security systems that are built into the Windows NT family of operating systems. Access Control Lists (ACLs) in the registry and the file system control access to the Workspace Virtualization Agent. 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. The Workspace Virtualization Agent moves the ACLs when a Virtual Software Package (VSP) is exported and imported.

The following table contains a description of how security works in several different areas for Virtual Software Packages (VSPs):

Table: Areas of security

Rights to modify a virtual software package

To modify a Virtual Software Package (VSP), a user must generally be a member of the local administrators group. The following are exceptions to the general rule:

  • Users that have read access to the HKLM\System\CurrentControlSet\Services\FSLX\Parameters\FSL\Rights\Activate key can activate VSPs.

  • Users with read access to the HKLM\System\CurrentControlSet\Services\FSLX\Parameters\FSL\Rights\Deactivate key can deactivate VSPs.

  • A user has the same rights to the files and registry keys in the redirection areas as if the application had been installed normally. This accessibility is not a problem if an application properly creates ACLs for its files during installation.

Rights to user-specific data

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 the information that is unique to each user. These unique areas exist under a SID directory that is named with a string representation of the user's SID. This directory contains subdirectories like the user's profile directory and desktop directory. You can see the SID directories in the Edit Layer dialog box on the Files and Registry tabs.

See Editing the files in a virtual software layer.

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 that is named USER_TEMPLATE. During the capture process, any user-specific data goes into this area. When any user uses the layer outside of capture mode, a SID directory is created for the current user. The contents of the USER_TEMPLATE area are copied to this directory. 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. For example, when the DESKTOP folder is created in the layer, the ACLs are copied from the user's base DESKTOP folder. This process ensures that only the proper users have rights to this folder.

When a layer is exported, the rights that are contained in the file system are represented in a file that is named 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.

Rights to start programs

When a layer is activated, the Workspace Virtualization Agent typically starts all of the items in the layer that are configured to run at startup. These programs run as the user who activates the layer. For example, when a layer is activated remotely by Notification Server, it happens in the SYSTEM context by default. Therefore, the Workspace Virtualization Agent does not start an item unless the interactive user who is logged onto the system does the activation.

This control over the starting of programs does not apply to the OnEvent actions. OnEvent actions are run regardless of how the layer is activated. You must ensure that OnEvent actions are executed according to your security policies.


Legacy ID



id-SF0P0173466_v57224467


Article URL http://www.symantec.com/docs/HOWTO50183


Terms of use for this information are found in Legal Notices