The Secure Workplace v4.0 | - by Jon F. Kaminsky |
he new v4.0 of Syntegration Inc.'s The Secure Workplace advances the art of OS/2 security. As a user of The Secure Workplace v3, I was not anticipating the degree of change that v4.0 brought to my Desktop. For this reason, a review of this nature cannot hope to cover all the new aspects of the Secure Workplace v4.0. Therefore, in this article, I will concentrate on the object security features that users will find most attractive, saving most of the administrative features and utilities for another review.
These new features add more flexibility, but for those more familiar with v3.0 of SWP, the new version requires a different mindset and the implementation may seem overwhelming at first. However, those more familiar with, say, Novell Netware's security functions, will be right at home. Although I'm no network engineer, having previously set up Novell Netware 3.12 for a former employer, I welcomed the similarity in function (although architecturally, SWP is a completely different product). Setting up security for users has been streamlined in v4.0 and it takes less time to navigate through the available options.
SWP v4.0 also enables single sign-on to a network operating system or remote host. With this feature, users only identify and authenticate themselves once. Single sign-on is accomplished by interfacing with the Network Sign on Coordinator (NSC), User Profile Manager (UPM), or your own custom program. NSC and UPM are provided with OS/2 Warp Connect, LAN Server, and OS/2 Warp Server. NSC works with Novell Netware File Servers and remote hosts.
The setup program starts with a dialog listing the installation options. For the default install (all options) you simply click "OK". The program files are copied to the location of your choice, and during this process the user is updated as to what files are being copied, the list of new classes registered with the WPS and the modifications made to the OS/2 config.sys file. During this time, the Secure Workplace folder (GIF, 7.6k) is installed automatically on the Desktop. In addition to several on-line guides, this folder contains program objects for such utilities as Sign-ON/Sign-OFF, Workplace Reset, System Shutdown, Object Editor, and the Object Manager.
Upon reboot, the user is greeted with the SWP login dialog (GIF, 7.6k). At this point, no Desktop objects are visible and if the User ID and Password are not supplied, you cannot progress any further. By default, until you explicitly change them, the User ID and Password are set to "userid" and "password" respectively. Therefore, the first thing you should do as the administrator is to change these default settings, and give yourself administrative privileges with the Security Administration object located in the SWP folder. This object opens a settings notebook where the administrator sets up users (including him or herself) either individually or as a group and grants certain privileges either on an individual basis or on a group basis.
The Privileges tab contains up to three pages depending on what object you are accessing. For example, the Desktop settings notebook privileges tab contains three pages: one for setting individual object privileges (GIF, 9.6k) such as copy or move, one for setting privileges for Desktop folder menus (GIF, 8k) such as sort or arrange, and one for the Desktop Menu (GIF, 7.7k) which allows or disallows the normal OS/2 Shutdown, Lockup, or System setup menu items. Drive objects contain the individual privileges page, the folder page and a Disk Menu page which controls access to the commands copy disk, check disk, format disk, and partition disk commands. (The partition command is not available to users.) Data or program objects simply contain the single page for individual privileges.
SWP handles security by allowing administrators to set up security for individual users or groups of users. Users are granted "Privileges" to objects on the Desktop or on any of the drives (or to entire drives themselves). Users are required to log on the system using a defined User ID and Password and once they pass this stage, they get the view of the Desktop and the privileges afforded them by the administrator. If so desired, guests can log on to the workstation and be afforded some level of function defined by the administrator.
A basic level of function for all users can be specified easily by setting up a group called "Everyone", and then adding all users (including guests) to that group. The Everyone group could be allowed, say, the "visible" and "open or execute" privilege which would allow that group's members to see and use any object on the Desktop, except drive objects and their contents. However, with only these privileges, a member of the Everyone group cannot copy, move, delete, shadow, rename, drag, drop, create another, or otherwise modify any object.
Because an object's security is controlled by the settings notebook, without access to this notebook, security for any object cannot be changed by a user unless he or she is granted that access by the administrator. However, while certain functions are removed from an object's pop-up menu by revoking privileges, clever users could circumvent some restrictions from the command line.
Therefore, for airtight security, administrators may also want to hide the OS/2 System folder so that users cannot open a command prompt or the System Setup icon. You can even restrict the Alt-F1 key combo to prevent users from accessing the Desktop Recovery function at boot-up, or prevent Ctrl-Alt-Del keyboard reboots. It's really that flexible!
The Geology group was given visible, copy, and open-execute privileges for the entire D: drive object, which contains nothing but data I wanted members of that group to be able to manipulate. Members of the Documents group were granted full privileges to the Documents folder on the Desktop. The users had full access to their own folders. All users were added to the Everyone group and were further set up as follows:
SWP proved to be very easy to configure, all options being set by the familiar OS/2 check buttons and pull-down list boxes. Once a user has been added to the system by the administrator, his or her name automatically appears in the settings notebook of every object. The best part is how easy it is to make changes after you have invested the time in deciding who gets what. For example, I decided Ward got transferred to the Documents group and therefore no longer needed access to Geology data, but now needed to work with Mary. Simply opening up the system administration setup and removing Ward from the Geology group and adding him to the Documents group changed his privileges across the board.
Security clearance was implemented dynamically as I repeatedly logged in and out as any one of my users. Logging in as Tom allowed me access to the D: drive object and I was able to work on data. Logging in as Mary revoked that access but gave me access to all files and folders within the DeScribe folder (so I could perform file maintenance duties) and I moved some files that I wanted Documents group members to work on to the Desktop Documents folder. Logging in as Fred set me back to the Everyone group security level but with the added function of being able to manipulate objects inside Fred's personal folder on the Desktop. I then logged in as myself to see what I could see. Once I was authenticated, the SWP utilities folder and OS/2 System folder magically appeared on the Desktop and my system basically performed as if I had never installed the SWP product -- complete unfettered access to everything!
Shadows seem to be somewhat troublesome to work with. Shadows are the rogue objects of any OS/2 system -- they retain properties of the parent object, and you can change properties of the parent object by changing the shadow, yet you can shred them with impunity. While SWP does provide security against the creation of shadowed objects, shadowed objects that already exist sometimes exhibit strange behavior (although never resulting in security breaches). This is more a result of how OS/2 deals with shadows than a deficiency in SWP. With SWP it is best just to avoid using shadows and if users need a program object on the Desktop, simply create an object for that purpose using templates.
It would also be nice for the administrator to see what privileges an object inherits by virtue of being a child of an object whose privileges were previously set. For example, DeScribe 5 installs 16 sub-folders inside the X:\DeScribe folder with additional folders rooted down into these. By inheritance, all folders and objects within the X:\DeScribe folder have the same security if set at the X:\DeScribe level. But suppose you want to change privileges for one folder or object within that structure. Opening the settings for that object does not display the inherited security from the previous changes made to the parent (X:\DeScribe) folder object. This isn't a limitation, but it would be a convenience some may appreciate.
Finally, I would prefer that Guests be prevented from changing the guest password. For example, a malicious guest could change the password from the default "Guest" and therefore prevent subsequent guests from logging on until the Administrator is called to reset the password.
The Secure Workplace v4.0
by Syntegration, Inc.
MSRP: $79.95 Standard edition
MRSP: $29.95 Standard upgrade
MSRP:$120.00 Professional edition
-- Copyright © 1996 - Falcon Networking
Our Sponsors: [InterStream] [J3 Computer Technologies] [Mount Baker] [Post Road Mailer]
This page is maintained by Falcon Networking. We welcome your suggestions.