CO k \ l F S U 5 I Ci / - - 9

Computational Physics and Engineering

COMPARTMENTED MODE WORKSTATION (CMW) COMPARISONS

J. S. Tolliver

"The wbmmed m a m t hss teen authored by a contractor of the U.S. Government under cmtract No DE- AC05-84M121400 Accwdngly. the U.S Government retains a narsxckrslve. royalty-trw llcense IO publish of reprodua, the DuMlshed form of fhls c m t r i b t m W allow others IO do XI fw U S Government wrp06Bs

presented at 1 7th DOE Computer Security Group Training Conference

Milwaukee, Wisconsin May 1-4, 1995

prepared for Oak Ridge National Laboratory

Oak Ridge, TN 37831 managed by

MARTIN MARIETTA ENERGY SYSTEMS, INC. for the

U.S. DEPARTMENT OF ENERGY under contract DE-AC05-840R2 1400

TE DISTRIBUTION OF THIS DOCUMEN7' IS UNLIMITED ). 8

DISCLAIMER

Portions of this document may be illegible in electronic image products. Images are produced from the best available original document.

Compartmented Mode Workstation (CMW) Comparisons*

J. S. Toiiiver Computational Physics and Engineering Division

Oak Ridge National Laboratory Oak Ridge, Tennessee 37831

Abstract

As the Compartmented Mode Workstation (CMW) market has matured, several vendors have released new versions of their CMW operating systems. These include a new version from Secureware** (CMW+ Version 2.4), and Sun’s CMW 1.1 (also known as Trusted Solaris 1.1). DEC is now shipping MLS+ 3.0 for DEC Alpha platforms. Relatively new entries in the market include Loral Bl/CMW for IBM RS/6000 platforms and a Secureware-based CMW for €-IP platforms (HP-UX 10.09).

With all these choices it is time for a comparative analysis of the features offered by the various vendors. We have three of the above five CMW systems plus HP-UX BLS 9.09, which is a multilevel secure operating system (OS) targeted at the B1 level but not a CMW. Each is unique in sometimes obvious, sometimes subtle ways, a situation that requires knowing and keeping straight a variety of commands to do the same thing on each system (“hmmm, is it getiabel or Mabe2 on this system; or something else entirely?”). Some vendors offer extensive GUI tools for system administration; some q u i r e entering command-line commands for certain system administration tasks. We examine the differences in system installation, system administration, and system operation among the systems. We look at trusted networking among the various systems and differences in the network databases and label encodings files. We examine the user interface on the various systems from logging in to logging out.

* * *

Research sponsored by the Office of Safeguards and Security, U.S. Department of Energy, under contract with Martin Marietta Energy Systems, Inc. Reference herein to any specific commercial product, process, or service by tradename, trademark, manufacturer, or otherwise, does not necessarily constitute or imply its endorsement, recommendation, or favoring by the United States Government, or any agency thereof.

1

.

This paper is not intended to be a “Consumer Reports” analysis that makes objective or even subjective decisions about which CMW systems is “best.” Rather, it is intended to be a comparative report listing the features of each system in such a way that those features can be seen clearly for each system, thus providing the interested buyer information upon which to base his or her choice.

Introduction

Our Trusted Database research project, funded by the DOE Office of Safeguards and Security, currently owns five trusted workstations with graphical user interfaces (GUIs) from four vendors. In using these systems for applied research into trusted databases in a heterogeneous environment, it has been necessary to attempt to understand the differ- ences and similarities among these four different trusted operating sys- tems. Our systems include four CMWs - two Sun CMW 1.1 (aka Trusted Solaris 1.1) systems, and one each of DEC MU+ 3.0 on a DEC Alpha platform and Secureware CMW+ 2.4 on an Intel Pentium plat- form. Our fifth trusted system is HP-UX BLS 9.09, a GUI multilevel system (MLS) at the B1 level, but not a CMW. In many ways, it can be thought of as a precursor to a CMW operating system. We have avoided upgrading to the HP CMW (HP-UX 10.09) because some of the features available on the MLS system are missing from Hp’s CMW. Trusted operating systems in general are complex enough that understanding just one requires nearly a full-time effort. In a heterogeneous environment with systems from multiple vendors, the differences among the different trusted operating systems compound the problems of system administra- tion. This paper will document what we have learned about the differ- ences and similarities among the four trusted systems described above, concentrating heavily on the three CMW systems.

All current CMW operating systems are built on top of some version of Unix and the X Window System, along with a trusted window manager. Strictly speaking, to say “built on top of Unix” is probably a misstate- ment since the B l/CMW security features completely pervade the oper- ating systems. However, to the user, the systems appear to be Unix-like with an X Window System interface. Indeed, at first glance, the systems appear to be standard Unix boxes with a bit of extra decoration around the windows. In all cases, the equivalent hardware platforms are avail- able, running a standard (i.e., nontrusted) Unix-like operating system with a standard X-based user interface. For the Secureware CMW running on an Intel Pentium platform, for instance, the analogous un- trusted system is SCO Open Desktop running on an Intel Pentiutn

2

platform. For DEC MLS+ on a DEC Alpha platform, it is DEC OSF/l; for Sun CMW, it is SunOS 4.1.3.

To the extent that the underlying Unix OSes are different from one another, the CMW systems are also different. SunOS 4.1.3, for example, is a BSD-based operating system. So Sun CMW 1.1 is BSD-like. Secureware, based on SCO OpenDesktop, is very much a System V user interface. And DEC MLS+, based on DEC OSF/l, which in turn is based on the Open Software Foundation’s OSF/l, offers yet a third major variant that appears to include most of the features of both BSD and System V. HP-UX BLS 9.09, like the untrusted HP-UX 9.0, appears to be primarily System V derived with many BSD features added.

Despite the subtle differences among the underlying Unix OSes, it is not the intent of this paper to analyze such differences even though those differences impact trusted operations. For example, each system estab- lishes a default router for internetworking in a different way, a situation that certainly impacts trusted networking. However, establishing that router is a difference among the analogous untrusted operating systems as well, not a difference of the trusted security features or operation. Even though such OS differences are well-known within the Unix community, the various versions of Unix remain fairly well standardized and inter- changeable. After all, that’s the whole point of the “Open Systems” concept.

Beyond the subtle and sometimes annoying Unix differences, each vendor has implemented the features prescribed by the Compartmented Mode Workstation Evaluation Criteria’ (CMWEC) and the Trusted computer system Evaluation Criteria2 (TCSEC, or “Orange ~ o o k ” ) documents in substantially different ways. Each vendor has supplied different levels of trusted networking. Despite valiant efforts on the part of all the vendors in the Trusted Systems Interoperability Group (TSIG) consortium, interoperating among multiple vendor trusted systems re- mains a Tower of Babel for the general consumer, especially on un- patched currently shipping products. As a ray of hope, however, several vendors promise more complete adherence to the emerging TSIG stand- ards for interoperability in the next release of their trusted OS.

Svstem Installation

One might guess that the easiest way to install a trusted operating system would be to order it preinstalled from the vendor. Our Secureware CMW+ 2.4 system came preinstalled, and we have not had the opportu- nity to upgrade to a new version; thus we have little experience with

3

Secureware installation. However, preinstalled CMW systems do not offer the conveniences that one might guess based on their untrusted counterparts. The primary reason is the Label Encodings file. preinstalled systems will almost surely come with the “standard” MITRE military- like encodings file specifying UNCLASSIFIED, CONFIDENTIAL, SECRET, and TOP SE(JRET classifications and military-sounding compartments, all from the MITRE label encodings document (Comparmented Mode Workstution Labeling: Encodings Forma?). That sample encodings file, while a useful and illustrative examplee, is almost certainly not what is needed at nonmilitary or commercial installations. Fortunately, theprein- stalled Secureware system came without any encodings file e n a b l e allowing us to install our own encodings file before any objects were labeled.

The Secureware software is available on 1/4-in. cartridge tape or ap- proximately forty 3.5-in. diskettes. We do not have a 1/4-in. cartridge tape reader for our Secureware system. We expect that reinstalling the CMW system, or upgrading to the next version, will be a painful and time-consuming process. The more mainline Unix vendors generally offer their trusted operating systems on CD-ROM (Sun and DEC) or 4 mm DAT tape (Hp).

We have had the most experience with Sun CMW installations due, in part, to having participated in the Sun CMW 1.0 and 1.1 beta programs. In addition, it seems that reinstallation of the Sun CMW system has been required frequently because of our incomplete understanding and inex- perience, some summer student experimentation, and the more complex operation options due to Sun’s use of the Network Information System (NIS, sometimes known as “yellow pages”) even for a single stand-alone system.

Sun CMW installation begins similarly to installing an untrusted SunOS 4.1 .x system from CD, setting the system up as a NIS master. The Sun CMW documentation describes the process in detail, though novice system administrators will require interpretation of many of the required steps. The comments below are not intended to be an installation guide; rather, they are intended to describe the flavor of the installation process. Installation occurs in single-user mode. If one is reinstalling, it would be wise to first save the existing IetclsecuritylTNETRHDB and letclsecu- @/label encodings files to floppy disk and reread those files when appropriate during the reinstallation process. Before reading from floppy disk during installation, one must first edit the letc/securityf$stab.adjunct file to define the information and sensitivity labels for the floppy disk drive. Other important files that one might want to save are letclhosts, letclm6.routes, letclrc.local, and lusrfo~enwinlliblCMWXdefaults. If any

4

editing of the TNETRHDB or label-encodings files is required during installation, then one must remember to set the information and sensitiv- ity labels back to the appropriate values after editing since the use of the editor changes the labels to those of the editor, not the original file. (7NETRHDB should have a SYSTEM-HIGH information label, while the sensitivity label of label encodings should be SYSTEM-LOW.) Early in the installation process, one must either reuse existing disk partitions or create new partitions. The only important difference from an untrusted SunOS install is that one must allocate sufficient space for the extensive CMW audit records, which are best placed on a separate partition. Near the end of the single-user install, one must set the NIS domain name and run ypinit -m to set up NIS. Then copy letclsecurityltcb dynamic and letclsecurityltcb static to backup files such as letc/se&-ityltcb dy- namic.orig and kclsecurityltcb-static.orig, for safe-keeping and future reference. Then comes one of the frequent Sun CMW mantras: sync ctub letclsecurityltcb - dynamic > > /sync-ctab. log followed by setlabe? sys- tem-high[system-high] letclsecurityltcb-dynamic lsync-ctab.log . Then a reboot command brings the system to multi-user mode. Setting up trusted printing requires further installation of Trusted Newsprint.

Installation of DEC MLS+ 3.0 is somewhat easier than the Sun CMW. It begins similarly to installation of a DEC OSF/l system. One must first plan the disk usage and set up disk partitions as needed, allowing space for audit records, preferably on a separate disk or partition. Installation reinitializes the system disk but does not change partition sizes. The installation manual suggests that one should backup the following files: Kernel config file, Encodings file, ItcblfilesmVETRHDB, ItcblfleslTNETIDB, letclhosts, letclfstab, ItcbljTlesIMACILBDBASE, ltcbflleslPACLDBASE, and customized files such as luSrlliblX1 lltmpams. Most installation options are set during the instal- lation process by responding to system prompts. One can choose either a basic or advanced installation. The basic installation makes assump- tions that limit the number of prompts; the advanced installation is more flexible but asks more questions. In the advanced installation, one must choose from about 30 optional software subsets to install, most of which will be wanted unless disk space is very tight. When the label encodings file is to be specified, there are three choices: (1) use the default encodings file (the MITRE/military one), (2) edit the default file using the ed editor, or (3) load a customized encodings file from some input media, We happen to have only a CD-ROM input device on our DEC Alpha system, and we don’t happen to have our site’s label encodings file on a CD- ROM, so one might think that the only option would be to manually edit the default encodings file during any reinstallation. Since that option is distasteful, a DEC engineer suggested the following trick First save the desired encodings file on some other machine on the network. Then,

5

choose the “edit default encodings file” option to get into ed. Once in ed, escape to the shell in order to set up networking (run ifconfis to configure the interface and create an letcliwsts file for the machine on which the old encodings file was saved). Then retrieve the file from the other machine using rsh, exit the shell, return to ed, delete the existing contents, read in new contents from the just-retrieved file, and write out the result. Sounds complicated, but it works. Having a floppy disk drive or a tape drive on the machine would be a more obvious solution, though not necessarily faster. DEC also provides a sample commercial encod- ings file that might be used in a commercial business establishment, though surely not without some customization for any one particular business. After getting the encodings file, the installation software in- structs that the system be rebooted, at which point the software subsets are configured, the root password must be supplied, and account names and passwords for Information System Security Officer (ISSO) and System Administrator are required. The root account is not a superuser in the standard Unix sense, but is a special account which has all kernel authorizations and base privileges assigned to it. Root should only be used during installation and in cases of emergency, such as a system crash. Then the kernel is configured and built, completing the installation. Afterwards, the system requires further configuration using DEC’s setup procedure to set up networking, mail, printers, etc.

Svstem Ad ministrat ion

The Trusted Facility Management (TFM) specification for CMW sys- tems requires that system administration be broken up into multiple roles. All of our systems use at least two roles - ISSO and System Adminis- trator (sometimes called “Admin”). It is the job of the ISSO to administer all security related aspects of the CMW. The System Administrator performs all other routine non-security-related tasks. Admin creates user accounts, but ISSO is required to enable those accounts after setting up security information (such as clearance ranges, etc.). Thus a two-person rule is in effect for creating and enabling new accounts. Some systems also define an “Operator” role, which is charged with performing day-to-day operations such as administering printers, performing system backups, and mounting removable media as needed. The term “System Administration” in this section is meant to include the operations of all roles, not just the “System Administrator.” As the CMWEC andTCSEC only specify the requirements that must be enforced rather than the user interface for how those requirements are implemented, the Sun, DEC, and Secureware systems all provide different user interfaces for system administration. HP-UX BLS, being targeted at B1 security, does not offer

6

such separation of roles.

Sun Trusted Solaris 1.1 System Administration The TCSEC requirement for CMWs is at the B3 level. This requirement states that system administrative personnel shall only be able to perform security administrator functions after taking a distinct auditable action to assume the security administrator role. Sun CMW implements this requirement with an Assume Role item in the Trusted Path menu. An ISSO or Admin account does not exist. Instead, a “regular” user who is authorized to assume the ISSO or Admin role uses the Assume Role tool to assume the ISSO or Admin role. Such role assumption is password protected with the user’s password, presumably to protect against abuse via an unattended terminal. After password verification, the ISSO or Admin “Role Menu” window appears with a list of the functions available to that role. Some of the functions are GUI tools chosen by selecting the desired function and pressing the Execute button. However, many ISSO and Admin functions are accessible only via a command-line interface. To perform these functions, the ISSO or Admin must choose the SYSTEM-HIGH shell or SYSTEM-LOW shell from the list of functions provided. Doing so opens up a “shell tool” window at the indicated sensitivity level. From this window many ISSO or Admin commands may be issued. For example, modifying /etc/security/7NETRHDB to add a new host or to change the attributes of an existing host would be done from this window by manually editing the Ne using tjhvi, the trusted version of vi. (There are also trusted versions of the view, vedit, ex, edit, and e commands.) These TFM editors are basically the same as their untrusted counterparts, except for having a restricted set of operations that can be performed. Operations not permitted include shell escapes, execution of Unix system commands, changing directories, and the preserve and recover commands. Changes may be saved for only those files specified on the command line when the editor is started. Fortu- nately, when in one of the TFM roles, the vi command is automatically aliased to &vi. One important point to note here is that ISSO and Admin must know when to work at SYSTEM_LoW and when to work at SYS- TEM_HIGH. Some commands are not available at SYSTEM-HIGH, but only at SYS’IEM-~W. But certain operations must be issued from a SYS- TEM-HIGH shell. For example, editing letclsecurity/7NETRHDB must be done at SYSTEM-HIGH, but editing /etc/~lfiles/alZ-cmdr must be done at SYSTEM-LOW.

Another TFM requirement at the B3 level is that “non-security functions that can be performed in the security administration role shall be limited strictly to those essential to performing the security role effectively.,*2 Sun implements this requirement by severely limiting the commands that can be issued in the SYS‘IEM-HIGH and SYSTEM-LOW shells. For exam-

7

ple, by default, the man and more commands are not permitted in these TFM shell tools. Not having man is very annoying since many of the commands that ISSO of Admin might need to execute are peculiar to trusted system administration and therefore unfamiliar to all but the experienced CMW administrator. Fortunately, since the TFM role is assumed by a “regular” user using the Trusted Path, that regular user generally has a shell tool window opened already (or can open a new one) from which the man command may be run.

The TFM roles are permitted to run cat and Is, for instance, but not having more is even more maddening than not having man since common operations like Is and cat often can produce output that exceeds the screen size. And, by default, the TFM shell tools are not scrolling windows. ISSO’s SYSTEM_LOW shell tool can have scrolling enabled but the SYSTEM-HIGH shell cannot even turn on scrolling. One solution is to use tfmview instead of more when one wants to merely look at a file’s contents, but that solution is not available for Unix pipes (Le., some- command-with-lots-of-oulput I more will not work since more is not available).

Fortunately, commands can be added to the list of commands available to the various roles, though the process to add a command is arduous. For example, to add more to ISSO’s list of allowed commands, first edit letcltj+nflleslall-cmds in a SYSl”EM-LOW shell and spec@ the full path to the desired command (lusrlucblmore). Then, since ISSO is not allowed to modify his own configuration, Admin must use the Configure Roles tool from the Admin Role Menu window to modify ISSO’s configura- tion. The Configure Roles tool is a GUI tool with a point-and-click interface for adding commands that appear in the all cmdr file to the list of commands that a TFM role is allowed to execute. At the same time, any privileges required by the added command must be specified, again using a point-and-click interface. No privileges are needed for rnore.The list of allowed commands and the associated privileges are kept in a database file, letclsecurityltfm role.cmds. Although this file is ASCII, it is not to be modified directly with an editor. It should be modified only by the Configure Roles tool. (Actually, in the M S environment, letclse- curityl@n-role.cmds is only the local copy. The master is in /efclnis/~-role.cmds on the NIS master and must be propagated to the NIS client and slave machines, if any.)

Following many system administration commands on the Sun CMW, one is advised to update the NIS maps and the TCB (trusted computing base) databases. For functions performed by the GUI tools, there is typically an alert box that pops up telling the user to update the NIS maps. Upon returning to the TFM Role Menu window, one must execute the

8

Update NIS Maps function. Whenever changes are made in a shell tool window, however, no such warning is provided. One is advised to issue the commands ypmake and sync-ctab letclsecurityltcb dynamic after editing most any system configuration Nes. otherwise, the system will likely hang, requiring shutdown to single-user mode, where those com- mands may be issued and the system rebooted. After only a few such episodes, one quickly learns to always remember the ypmake and sync-ctab mantra.

DEC M U + 3.0 System Administration The DEC system generally has a nicer interface for system administra- tion. Almost all TFM duties are handled through GUI tools. There is no need to run ypmake or sync ctub or equivalent commands. Adding or modifying hosts in TNETRH>B, for instance, is handled via a GUI tool accessed from the Network ZSSO tool. All features of TNETRHDB can be changed from this GUI tool. A nice “template” feature is available in which most of the characteristics of a particular class of hosts can be defined in the template. Then each new host is given the template that does most of the configuration for that host. For example, there are templates for single-level connections to untrusted hosts, for MaxSix connections, and for TSIX(RE)l.O connections. These templates define the session management type, the network labeling type, session attrib- utes, accreditation range, maximum privileges to allow, etc. To add a new TSIX host, one simply adds the hostname and IP address and selects the TSIX template. Templates can be created and modified using GUI tools. One can also edit the ltcblfieslTlVETRHDB directly with an editor, if desired.

GUI tools are provided for almost all common system administration tasks. There is no explicit assumption of roles. The GUI tools for ISSO’s functions are available in the Trusted Path menu for any user who is authorized to act as ISSO and similarly for Admin functions. However, there is no password protection for an unattended terminal. There is usually no need to run man since all the tools have Help buttons that bring up a hypertext-linked help window using DEC’s BookReader applica- tion. Many operations have context-sensitive help as well. Any error messages or output that may occur from using the GUI tools appear in popup dialog boxes.

Some commands and operations must be issued from a command-line interface. For these, there are the ISSO and Admin user accounts with passwords. An example would be trusted system recovery after a crash. There is also a Start Application tool in which authorized users can issue trusted path commands (those residing in lusrltcbltpath and ltcbltpath) while specifying the sensitivity label at which to run. An example would

9

be ltcblpathlchpriv to change the privilege sets on files. Output from applications started with Start Application appears in the dxconsole window.

Secureware CMW+ 2.4 System Administration Secureware is almost completely GUI based with tools accessed from the Trusted Path menu. Almost all tools have Help buttons which bring up a help box containing text that explains the current window. This help box is not a hypertext-linked help document, but a linear help file explaining all the input fields and buttons in the current window. The help box is modal; it must be dismissed with the OK button before continuing with one’s work in the original window. Many times, when bringing up a new tool, the sensitivity label of that tool is required. When needed, the standard Secureware Set Program Sensitivity M e 1 window appears in which the desired label is chosen with a point-and-click interface.

For users authorized to perform the various roles, there are ISSO Func- tions, Administrator Functions, and Network Administrator Functions items in the Trusted Path menu. These items bring up the appropriate tools. The Secureware tools differ from the DEC tools in that each tool has an output-only terminal-like area in which diagnostic information appears.

The Network Administrator Functions are similar to DEC’s Network ISSO tool, though adding a host to Secureware is much more involved than on the DEC system, due in part to a more complete implementation of MaxSix (“M6”) networking by Secureware. Secureware includes all the Domain of Interpretation (DOI) and Domain of Translation (DOT) features and M6 mappings to map between nonidentical label encodings files on different trusted systems. None of those features is included in the current DEC or Sun CMW products. Secureware has no template feature but it does have a feature in which once a host type is defined and configured, other hosts may be added to share that same configuration. However, due to the user-interface design, adding a new host on Secure- Ware remains a multistep, multiclick operation involving several win- dows, with little clear direction on the steps required other than those in the manuals or in the help boxes.

Trusted Networking Each of our three CMW systems implements some of the features of emerging trusted networking standards. Sun uses MaxSix 1.0 but cannot interoperate with Secureware’s newer MaxSix. DEC has both MaxSix 1 .O and TSIX(RE) 1 .O (from TSIG) but does not yet support DOI, DOT, or M6 mappings. Secureware has MaxSix version 2.3 but not yet

10

TSM(RE) 1 .O. It is not the intent of this document to explain the complex world of trusted networking or even all the acronyms, but rather to explain some of the differences among the various systems.

Each vendor can interoperate with another of its own type. For example two Sun C M W s can communicate with one another. But when one attempts to expand that world into a heterogeneous environment, many problems are encountered due to incompletely implemented standards. HP uses MaxSix 2.3 and in general can interoperate well with Secure- Ware. Sun and DEC both support MaxSix 1.0. DEC supports the latest standard, TSIX(RE)l.O but not MaxSix 2.3. As aresult, all of our systems can interoperate with some other system but not all. DEC and Sun can communicate using MaxSix 1.0. DEC and Securewareusing single-level session management and CIPSO network labeling. Secureware and Hp can communicate using MaxSix 2.3. Since this trusted networking field is rapidly changing with TSIX(RE)l.O emerging as the standard and with at least DEC and Secureware promising imminent new versions of their operating systems more fully supporting the standard, there is little point into explaining the current status or detailed information about how to set up networking using the current products. One point to remember, though, is that with current versions of the various OSes, it is best to use the identical label encodings files on all systems. Unfortunately each of our CMW systems supports different versions of the label encodings format3. DEC supports the latest 2.2 release; Sun ,the 2.0 format; and Secureware, the original 1.0 format. Fortunately, the formats are similar enough that almost identical label encodings files can be used on each system, with the exception that Sun has added some required fields to their usage of the label encodings file to define label colors and printer banners. The other vendors define those fields in secondary files.

Svstem Oneration

Operating the three CMWs and the one MLS machine is confusing due to the different ways that the security features are applied at the user level. For example, Sun uses getlabel to display file labels while DEC and Secureware use Islevel. Sun uses setlabel to change a labek DEC and Secureware use chlevel. All three use lspriv to list the privileges assigned to a file, but the meanings of the privileges are different among the three systems. DEC and Secureware let users temporarily change their base privileges with the privs command. Sun, which uses a slightly different scheme for determining effective privileges from base privileges and kernel authorizations, has no such privs command.

11

Even the windows look and behave differently on the three systems. Sun’s trusted window manager is OpenLook-based while DEC and Secureware use Motif. Opinions aside about OpenLook versus Motif, using both certainly creates confusion. If we could have a Motif look and feel on our Sun CMW systems, we would gladly choose it for compati- bility reasons. DEC’s trusted Motif window manager puts the label stripe under the Motif window title bar. Windows can be dragged using the title bar at the very top of the window. Clicking on the label stripe instead, or by accident when aiming for the title bar, brings up a system-modal dialog box containing the complete window label. Secureware’s Motif win- dows are laid out in just the opposite fashion. Windows are draggedusing the Motif title bar in the usual manner, but the security label stripe is at the very top with the Motif title bar below. Sun has the security at the top and the OpenLook title bar below, but windows can be dragged using either the security stripe or title bar. To bring up a label expansion, the right mouse button is used in the label stripe to bring up a menu to show the full label or to set the input information label. Setting the input information label on the other two systems is a Trusted Path operation.

It is not the intent of this paper to explain in detail all the differences of the three CMW systems, but rather to provide a flavor for how they are different. More examples and information will be provided in the accom- panying talk. Just one more example will be given here. The procedure to open a new window at a new sensitivity label differs greatly among the three systems. Sun is the most laborious, using a Trusted Path menu requiring three clicks to bring up a window to set the label of the “Workspace menu.” Then future shell tool creations will be at that sensitivity label. DEC uses the Start Application tool to specify the label of the application to be started. Secureware is the easiest, with the Set Program Sensitivity Label window appearing automatically with no extra user intervention each time a new window appears.

Conclusions

Setting up a CMW shop with products from just one vendor is certainly the easiest route. However, when a heterogeneous environment is needed, additional time and perhaps personnel to manage the heteroge- neous mix of machines will be required. We should encourage our vendors to strive for more commonality among commands and user interfaces and to more fully support the emerging trusted interoperability standards. The TSIX(RE)1.0 effort by TSIG has proven to be a near success with at least DEC and Secureware promising to support it. So in future versions of the CMW OSes from these vendors, trusted net- working should be much easier. However TSIG also has the Trusted

12

Administration Working Group (TADM) working toward standard sys- tem administration tools. Alas, there has been little acceptance of TADM efforts, and the effort seems to have been all but abandoned. We can only hope that future CMW systems will be easier to operate and will be more alike than they are different.

References

1. Compartmented Mode Workstation Evaluation Criteria, Version I , Defense Intelli- gence Agency Document DDS-2600-6243-91, June 1991.

2. Department of Defense Trusted Computer System Evaluation Criteria, Department of Defense Standard, DOD 5200.28-STD, December 1985.

3.Compartmented Mode Workstation Labeling: Encodings Format, Defense Intelli- gence Agency Document DDS-2600-6216-91, June 1991 (and succeeding versions).

DISCLAIMER

This report was prepared as an account of work sponsored by an agency of the United States Government. Neither the United States Government nor any agency thereof, nor any of their employees, makes any warranty, express or implied, or assumes any legal liability or responsi- bility for the accuracy, completeness, or usefulness of any information, apparatus, product, or process disclosed, or represents that its use would not infringe privately owned rights. Refer- ence herein to any specific commercial product, process, or service by trade name, trademark, manufacturer, or otherwise does not necessarily constitute or imply its endorsement, recom- mendation, or favoring by the United States Government or any agency thereof. The views and opinions of authors expressed herein do not necessarily state or reflect those of the United States Government or any agency thereof.

13

‘ I I, .