Secure Deployment and Whitelisting

Manually Configure a SandBox with Whitelist Entries for Files and Programs

The SandBox feature allows administrators to restrict user access to files and programs on a Webspace host (server) based on whitelist entries. These restrictions apply to users only, not to administrators or members of the Administrators Group. As a security practice, GE recommends assigning least-privileged user accounts for Webspace access. This is a security configuration hardening feature, which allows only the executables required for iFIX or CIMPLICITY to be launched through the Webspace interface. It helps mitigate security risks associated with unintended usage of Webspace.

Whitelisting Overview

The Webspace server installation does not include a user interface for configuring SandBox white list entries. You can, however, manually edit the WorkspacePropertyDefinitions.xml file (typically in the C:\ProgramData\Proficy\WorkspacePropertyDefinitions.xml folder) to add files and programs to the white list for a Webspace server installation. The SandBox feature for files and/or programs must be enabled before specifying white list entries.

How the Whitelist Works

Whitelisted files are specified by a fully qualified directory path. The SandBox will allow access to all files within a directory that is listed in the whitelist for files, including subdirectories. The WorkSpace profile directory, %USERPROFILE%, including all subdirectories, is automatically added to the files whitelist when a session starts.

Programs can be added to these desktops in four ways:

• Place the actual program executable module in a desktop folder. (for example, C:\Users\Public\Desktop\ExampleApp.exe)
• Place a shortcut to the program executable module in a desktop folder (for example, C:\Users\ExampleUser\Desktop\ExampleApp.lnk)
• Place a document that has an associated program in a desktop folder (for example, C:\Users\Public\Desktop\ExampleDoc.doc)
• Place a shortcut to a document that has an associated program in a desktop folder (for example, C:\Users\ExampleUser\Desktop\ExampleDoc.lnk).

Once the WorkspacePropertyDefinitions.xml file has been edited, the changes must be propagated to the DefaultWorkspaceProperties.xml file as shown in the next section.

Configuration

The Webspace product will deploy a WorkspacePropertyDefinitions.xml file that will include all paths and programs needed by iFIX and CIMPLICITY, but with the default set to disable SandBox. After installation, the Application Publishing Service generates a DefaultWorkspaceProperties.xml file from the values in the WorkspacePropertyDefinitions.xml file. The Application Publishing Service derives its settings from the DefaultWorkspaceProperties.xml file.

System administrators can make additional changes by editing DefaultWorkspaceProperties.xml.

Enabling the SandBox Feature

For files:

1. Stop the Application Publishing Service.
2. In a text editor, such as Notepad, open WorkspacePropertyDefinitions.xml.
3. Locate the filesSandboxEnabled property id, set the value to true, save the file, and restart the Application Publishing Service.

   <propertygroup id="UserSandbox">
   <property id="filesSandboxEnabled">
   <label>User sandbox</label>
   <description>Enables the user sandbox feature.</description>
   <type>BOOL</type>
   <defaultvalue>true</defaultvalue>
   <constraints/>

For programs:

1. Stop the Application Publishing Service.
2. In a text editor, such as Notepad, open WorkspacePropertyDefinitions.xml.
3. Locate the programsSandboxEnabled property id, set the value to true, save the file, and restart the Application Publishing Service.

   <property id="programsSandboxEnabled">
   <label>Programs</label>
   <description>Users may only run programs specified in the Programs white list.</description>
   <type>BOOL</type>
   <defaultvalue>true</defaultvalue>
   <constraints/>

Important Information

Be aware of the following:

• The value for filesSandboxEnabled in the WorkspacePropertyDefinitions.xml is case-sensitive and must be all in lowercase ("true" or "false").
• When using filesSandBoxEnabled=true, and iFIX is not installed to the default install folder, the root drive of the iFIX installation needs to be allowed read access. For example, add the line "E:\", ACCESS_READ | ACCESS_ALLOW_VISIBLE_CHILDREN; to the filesRequiredWhiteList section. Also, if the documentation is not installed to the default install folder, make sure that the ProficyDoc folder is denied access by listing it in the WorkspacePropertyDefinitions.xml. For example, change "%ProgramFiles(x86)%\Proficy\ProficyDoc",ACCESS_DENIED; to "E:\Program Files (x86)\Proficy\ProficyDoc",ACCESS_DENIED;

Adding Folders to the Whitelist

<property id = "filesWhiteList">
<label>Files</label>
<description>Files and directories that users are allowed to access from the session.</description>
<type>STRING</type>
<defaultvalue>
</defaultvalue>
<constraints></constraints>
</property>

<property id = "filesWhiteList">
<label>Files</label>
<description>Files and directories that users are allowed to access from the session.</description>
<type>STRING</type>
<defaultvalue> "C:\Departments\Accounting\Templates",; "%ALLUSERSPROFILE%\ExampleApp",;
</defaultvalue>
<constraints></constraints>
</property>

Adding Program Files to the Whitelist

<property id = "programsWhiteList">
<label>Programs</label>
<description>Programs that users are allowed to run from the session.</description>
<type>STRING</type>
<defaultvalue>
</defaultvalue>
<constraints></constraints>
</property>

You can add multiple program file paths between the <defaultvalue> tags, using one path per line, enclosed in double quotes, no leading white space, ending with a semicolon (;). Expandable environment variables can be included.

<property id = "programsWhiteList">
<label>Programs</label>
<description>Programs that users are allowed to run from the session.</description>
<type>STRING</type>
<defaultvalue> "C:\ExampleApp\bin\ExampleApp.exe"; "%SystemRoot%\regedit.exe";
</defaultvalue>
<constraints></constraints>
</property>

Applying Whitelisting Dynamically

The most efficient way to apply any whitelisting changes is as follows:

1. Stop the Application Publishing Service.
2. Delete the DefaultWorkspaceProperties.xml file.
3. Edit the WorkspacePropertyDefinitions.xml file.
4. Re-start the Application Publishing Service.

A new DefaultWorkspaceProperties.xml will now be generated.

An easier way to make changes is to simply modify the DefaultworkspaceProperties.xml file itself. This doesn't require an APS restart. But be aware that if this modified file ever gets deleted, the edited settings will be lost since an APS restart will generate the file from WorkspacePropertyDefinitions.xml. As a best practice, you should keep a backup of a working XML.

Custom Applications

For custom applications, you will need to add the path and the programs to the corresponding lists (property id="filesWhiteList" and property id="programsWhitelist") with the right permissions to the path (ACCESS_READ | ACCESS_WRITE, ACCESS_ALLOW_ALL_CHILDREN, ACCESS_ALLOW_DESCENDANTS, or ACCESS_DENIED).

CIMPLICITY Project Paths

You will need to add all project paths to "filesWhitelist" with ACCESS_READ, ACCESS_WRITE, ACCESS_ALLOW_ALL_CHILDREN, and ACCESS_ALLOW_DESCENDANTS permissions.