Components

The user environment was developed under the SCO UNIX 3.2 2 environment. All hosts and terminals use an alphanumeric display rather than a GUI. The key components to the finished user environment are listed here.

1. All users log in using the stock Restricted Shell (rsh). While the rsh in and of itself does not guarantee a secure system, it adds a significant level of protection against unauthorized access.

2. A single master profile is linked to each user's $HOME/.profile (dot profile). The system administrator must make this change after adding new rsh users. This .profile is substantially modified version of the .profile normally installed by the sysadmsh -- the SCO system administration utility. Linking $HOME/.profile to a master profile makes it very simple to upgrade the profile for all customers on the system.

3. The Oracle shell kickoff program oraenv, which is executed as the last statement in .profile, is modified to call a Login Menu.

4. The Login Menu is run from the user's $HOME/bin directory but is linked to a master Login Menu. The master Login Menu on each host provides access to a set of generic services available to all hosts, as well as to the applications available only on that particular host. Putting a linked copy of the master Login Menu in each user's working area makes it a simple matter to upgrade the menu for all users. Calling the Login Menu from .profile protects user from the hazards of working from the command line, and eases the system administrator's concerns about UNIX training, restoring accidentally deleted data, unauthorized access, etc.

The Restricted Shell

The toughest part of developing the user environment was getting everything to work in a restricted shell. We learned to ask whether a product had been tested to work in the Restricted Bourne Shell and whether, if it had shell escapes, those escapes could be administratively disabled. One product failed completely because it contained hardcoded exec's, which are prohibited in the rsh. The inability to perform output redirection operations severely handicapped administrators and developers. Ultimately, we wrote a C utility to provide output redirection functionality so that we could append data to UNIX log files and write shell scripts on the fly. Even experienced developers had to check code carefully for illegal output redirection, use of "/" in a command, PATH or directory changes, or use of exec. A locally produced on-line tutorial on developing for the restricted shell is now required reading for new developers.

Our rsh user's PATH does not include either /bin or /usr/bin. A separate /usr/rbin directory was created to store selected standard and custom UNIX utilities from /bin and /usr/bin. Utilities with shell escapes, or other historically known security problems, were not included in /usr/rbin, and some standard utilities, such as cat, were replaced with substitute utilities written to limit the functionality of the originals. The cat substitute, for example, can only read files from specified directories hardcoded in the utility. For security and training reasons, rsh users cannot access the vi, pg, and more commands, but comparable functionality is provided by an easy-to-use read-only file browser, with built-in file download capabilities. So far, no one has found a way to break out of the Login Menu or any of the available applications to access a command line. If it should happen, however, limiting the available commands will hamper attempts at unauthorized activity. (Note: code for several of the substitute functions is included with the electronic code distribution -- see the Source Code Availability listing on the cover.)

The User Profile

When the SCO system administration utility, sysadmsh, creates a new user, it automatically installs a system default .profile in the user's $HOME directory. Two of the design specifications -- a simplified user interface and no access to the command line -- entailed changes to the default .profile. For our purposes, the primary work of the profile is to establish the $TERM, establish Oracle environmental variables, and start-up the Oracle shell, which in turn starts up the Login Menu. The actual TERM assignments in the Master Profile in Listing 1 are unique to our hosts and will not apply to any other hosts. The tradeoff for making the user interface as convenient as possible at the application level was complicated maintenance of terminal definition at the UNIX and application levels.

Listing 1 demonstrates important working parts of the modified profile. Since we use Oracle, the user profile has to initialize the special Oracle shell. With the normal Bourne shell, this is no problem -- the oraenv shell script is called as a dot file in the last statement of the profile. Running under rsh required modification of this script.

Normally, the user profile is a discrete file located in the user's $HOME directory. This would have been a maintenance nightmare when revisions were required, and would have taken precious disk resources for hundreds of users. The maintenance problem is compounded by the fact that we have several login hosts. Since it wasn't necessary for each user to have a unique login profile, the solution was to link each user's profile to a "master profile". However, if it became necessary to establish a unique login environment or run a special login initialization for an individual user, the master profile could simply check for the existence of a generic initialization filename and execute it (as a dot file if necessary).

The Login Menu

The Login Menu insulates our users from the UNIX command line. The menu itself is really not that important in the scheme of things: it is simply the means by which users can get to the computer programs they need. Some of the considerations in designing the menu were: easy/intuitive user interface, easy to maintain (and figure out) by new administrators, ease of maintenance across several hosts, responsiveness to rapidly evolving system requirements, and screen display speed for 2400-baud dial-up users. Listing 2 shows a Main Login Menu template.

It seemed that a menu system which consisted of a single shell script file would be easiest to understand and maintain. Additional support files (announcements, help) could be located in a closely related directory. I was concerned that the menu code might eventually grow too large for the operating system, or user memory. But so far, at about 80K bytes for the production menus, both the menu and the Oracle programs still work. The menu has four basic tasks:

1. Display the Main Login Menu, a single screen of 52 choices.

2. Get a single alpha key and an <ENTER> to activate a choice (requiring <ENTER> allows a change of mind or correction).

3. Run the selection activated by the choice.

4. Loop on 1-3 until Exit is selected.

Because the Login Menu displays all applications and utilities on a single screen, screen paint delays are minimized for the benefit of the 2400-baud dial-up users. Application screen paints may be slower, but there's not much I can do about that. The menu choice mechanism is similar to the PC interface many of our users encounter in their offline PC work.

Because the overall system being constructed was in development, I knew that the Login Menu would change regularly. To avoid making changes to hundreds of individual copies of the menu, I linked each user's $HOME/bin/.menu to a master menu which can be changed at any time. The /usr/public/menu master is owned by root and its permissions are set to 755. Shell script functions that help to modularize the menu into the four basic tasks described earlier also make it easier to implement any enhancements to the generic menu on all host systems.

The template shown in Listing 2 can be used where all users see the same menu. Where not all users will have access to all functions, the menu can be enhanced to check a list of authorized users of a particular selection before starting up the selection. The authorized user list would contain the login userids that are permitted to run the application. Like the /etc/passwd file, the list would contain colon-separated information for each user. The Login Menu or application can then be designed to check for extended access authorizations.

As you can see from the menu template, I wrote several custom C utilities. These are described in the following paragraphs.

ftim.c

One of the requirements of the user environment was to collect various login and application statistics. While the UNIX date utility provides good human-readable time formats, I found it inadequate for generating time stamps to be compared. ftim is a C utility which returns a single long integer (time_t) value which is the current time in the number of seconds since 00:00:00 January 1, 1970 (on SCO UNIX). I've also included source for two other related C utilities: fcvtim.c, which converts the long integer value from ftim to a human readable time/date form, and fgotim.c, which converts an historic time to a long integer value. These second two utilities were designed for use in shell script programs which gather and report information from the login and accounting logs.

menucat.c

I needed a utility which could quickly display a screen full of information, much as UNIX cat does. However, if someone were to find a way to break out of the Menu to a shell command line, I didn't want them to have access to cat, pg, more, or vi to do unauthorized shopping. The menucat utility displays any file from the current directory ($HOME/work), or from any directory which is hardcoded in menucat. Using menucat to display a file outside of these limitations results in an error message.

termlock.c

Because it may take several minutes for a user to navigate several LANs to eventually attach to our hosts, we needed to provide a security conscious means of allowing the user to walk away from the terminal for a few moments. This is a password-protected terminal locker. Our systems also use an idle time program. In order for the termlock program to avoid the idle time program, termlock periodically refreshes the user's screen with a terminal secured message.

echoto.c

The Bourne Restricted Shell prohibits the use of output redirection operations (>, >>). This proved to be too great a restriction on developers. The echoto utility is used to append login and accounting information to the log file, and is used by developers to build shell scripts on the fly for an Oracle report generator.

pager.c

This is a homemade, easy-to-use, read-only file browsing utility (see the sidebar, "About the File Browser," for a detailed discussion). This utility replaces such commands as more, pg, less, and view. On our hosts, system administrators use pager to display extended messages, announcements, and help screens, while the Oracle developer uses it to let the user look at reports immediately. In addition, pager allows the user to mark all or a portion of the displayed document and download the marked portion to a PC or print on a dumb terminal with attached printer.

(Editor's note: Source for these utilities is included in the electronic code distribution for this issue, but is too lengthy for publication. See "Source Code Availability" -- page number is on the cover -- for information on electronic code distribution.)

One Final Precaution: Checking for Multiple Logins

For security reasons, the user's $HOME/.profile was also modified to check for a user attempting to login more than once. If a second simultaneous login attempt is made, the login is denied and a second-login-attempt message is sent to the system administrator, who will contact the user regarding a possible security violation. There have been a few cases where a user legitimately needed several simultaneous logins to run programs that were not designed to run as background processes. We gave that user access to several different userids, which turned out more efficient.

Conclusion

While debugging and getting used to the rsh took a bit of time, the final user environment has now been operating successfully for over a year. There have been no complaints from users regarding difficulty and no security violations caused by a hole in the login environment. One of the benefits of producing your own user environment from scratch is that you know all the intricacies of the software -- there are no hidden backdoors unless you put them there. If someone finds a crack in the security wall, you can figure out how to fix it.

As it turns out, one of the most challenging tasks has been training application developers and system administrators in the use of the Bourne Restricted Shell. While the rules aren't all that difficult, the remembering to abide by them sometimes is. By encouraging developers to regularly test their new software in the rsh environment, we do manage to avoid the big problems.

About the Author

Fred Lenk earned a master's degree in Music form California State University, Northridge. He was with Burroughs-Unisys for nine years, as a senior instructor and senior systems analyst. He is now a Computer Specialist with the U.S. Navy. Opinions in this article are Fred's alone and do not represent those of the U.S. Navy.