Preventing Direct Access To Data Inside LK and OV Files (Deployment,Installation)
Created at 27 AUG 2010 02:16PM
Contents:
Overview
Planning Security
Example Environment
Applying Changes
Design and Deployment Considerations
Overview
Protecting and auditing access to data is a common requirement for compliance with industry security standards like the PCI DSS (Payment Card Industry Data Security Standard). This article covers one method to prevent unauthorized access to OpenInsight data inside LK and OV files using strict NTFS permissions. If users can't directly read or change LK and OV files you can audit and protect access to data using controls internal to your application.
Environment & Prerequisites
This article applies to run time deployments of OpenInsight 9.2+ and the Universal Driver 4.6 with the LinearHash service.
Please note that AREV32, CTO, and OpenInsight versions prior to 9.2 may require additional security configurations not covered by this document.
Applications can be deployed from a network share or on a terminal server.
Prior knowledge of installing OpenInsight and the Universal Driver is recommended. If you are not familiar with these topics you can still apply the security concepts to your installation but following this procedure step by step will be difficult.
General familiarity with NTFS and share security is helpful.
Caution: This article does not cover locking down permissions for applications under active development. Attempting to change or develop an application with restricted user rights designed for run time deployment will be problematic. Please see the list of deployment and design considerations at the end of this article.
Planning Security
At minimum you will need one user (or group) with full access and a restricted access user (or group). Full access should only be used when applying application updates or maintenance on OpenInsight. Restircted access should be applied to all users for daily operation of the application. These access levels apply at the operating system level, not the application's user list.
No NTFS deny permissions will be set. Instead, our full access user will be given complete control leaving all other accounts/groups to gain access through the "Everyone" group. The "Everyone" group will be limited to read or read and execute access to files.
Example Environment
This article is based on the following environment.
Windows 2008 Server and Windows 7 workstations joined to the LAB domain
Default installation of OpenInsight 9.2 and Universal Driver 4.6 with LinearHash service
Full access user/group: LAB\Administrator user and SYSTEM
Restricted user/group: "Everyone" group
Applying Changes
The security changes are set using the iCACLS utility from a BAT script. This utility is included with Windows 2008. Permissions can be set by hand but to streamline and reduce errors most of the steps are scripted. The example script available for download in the next section performs the following tasks:
1. Reset security on the OI directory.
2. Grant full access permission to appropriate users.
3. Remove inherited security from the OI parent directory.
4. Remove all access from the restricted user as a sanity check.
5. Grant read and execute permission to the restricted user on all files.
6. Remove the restricted user's read permission on all .LK and .OV files
The next two sections walk through using the script and checking the results.
Download and Execute the Permission Script
1. Download the secure_oi_lk_ov.bat file.
2. 
3.
4. Edit secure_oi_lk_ov.bat and change the SET statement variables OIROOT, APPADMIN, and RESTRICTED to match your environment.
5. 
6.
7. IMPORTANT: In the next step the script must be run as the user or group member specified in the APPADMIN variable. Otherwise your account may be prevented from making further changes to the files. If this happens you must take ownership of the OIROOT directory as the APPADMIN user and repeat this section.
8.
9. Execute the script and wait for the script window to close.
Permissions on the OIROOT directory have been changed and the last two sections walk through checking the results from the server and workstation.
Checking Security From Server
To prove security is properly setup you need to check at least 2 files in the OInsight directory.
1. Verify .LK/.OV files are secure by viewing the security properties of one of the files. Your screen should match the image below. Notice the "Everyone" user does not have read access.
2. 
3.
4. Also check any files that do not end in .LK/.OV to verify the restricted user has Read and Read/Execute access as shown below.
5. 
6.
Checking Security From the Client
1. Use Notepad to open any LK or OV file in your OpenInsight application. You should receive an access denied message as shown below.
2. 
3.
4. If you did not receive the access denied message you are either signed in as an administrative user or the permissions were not correctly set. Check the NTFS permissions of the file against the user name you connected to the server as.
5.
6. Finally, launch OpenInsight and verify the application functions correctly. If it functions correctly you have successfully applied the security permissions.
These directions will ensure basic operation of OpenInsight applications. Depending on the application developed inside OpenInsight and features utilized you may encounter additional security needs. The next section discusses additional considerations.
Design and Deployment Considerations
Permissions should always be considered during the development phase of your application. This section covers the additional security requirements that may apply to complex applications. Generally, a fresh installation of OpenInsight doesn't require additional security setup.
Application DBT Settings
The Database Manager window controls which tables are automatically attached to the application during startup. This list is stored in the root OpenInsight directory with a naming convention of <APPNAME>.DBT. Changes to the DBT file or the Database Manager should be performed with Administrator rights.
Other actions that indirectly alter the DBT file are adding indexes to previously un-indexed tables, rebuilding all indexes on a table, and calling define_database() function. These actions should be done from a login with Administrator rights so the DBT file can be properly updated.
Temporary Files
Whenever possible temporary files should be created on the local workstation. The path to the Windows temp folder is returned by making a call to GET_SORT_PATH("%TEMP%"). If a common temporary file/folder is required on the secured application share then file and folder permissions should be used to secure the application.
Sort Path
By default OpenInsight 9.x ships with a database sort path set to %TEMP%. This variable resolves to a sort file located in the temp directory assigned by the operating system. If this setting is not set to the temporary directory verify that the application users have read/write access to the location.
Transaction Log Path
The default transaction log path setting is "TRANSACT" which is a directory relative to the oinsight.exe program. If the application uses transaction logging this setting must be checked.
If file and folder permissions are used to secure the directory simply allow read/write access to the TRANSACT folder in the OpenInsight directory.
If share level permissions are used this setting must be modified. By default share level permissions will not allow the creation of tables in this directory. One of four possible solutions exist for this situation.
1. Setup a separate share with read/write permissions specifically for the transaction logs. Be sure to include a copy of the REVPARAM file from your application directory.
2. Use an absolute path on the local workstation for the transaction logs.
3. Use file and folder permissions and specifically grant read/write access to this folder.
4. Create the transaction log table in advance.
Note: Options 1 and 2 require an absolute path. Whenever possible Revelation Software recommends all paths be relative to the OpenInsight directory. To keep relative paths, file and folder permissions must be used.