This chapter is designed to educate the system administrator on the differences between communications under Trusted IRIX/CMW and under standard IRIX. It is assumed that the system administrator is familiar with networking software as described in the guide titled IRIX Admin: Networking and Mail . Where information in this chapter differs from the information presented in other IRIX documentation, this chapter must be considered authoritative for Trusted IRIX/CMW.
The following sections are included:
A central concept to the SGI product family is that the most effective way to bring computing power to the individual is to connect the workstations and produce a unified system of great power. This connection allows the workstations that make up a Trusted IRIX/CMW system to share a common set of files by use of the NFS filesystem sharing protocol. It also allows computing resources to be shared via TCP/IP protocols. This mechanism allows file resources to be shared among users, who find a single filesystem presented to them, while still providing the convenience and security of a personal workstation.
The key premise of trusted networking is that arbitrary and capricious information is never encountered. In order for this to work, the networks must be physically secure, the systems connected to the network must be appropriately administered, and the systems may either be trusted to enforce the network security policy, or are otherwise trusted and cleared to the network high label at all times.
The network is a critical part of each system's Target of Evaluation (TOE) and must be subject to the same security standards that prevent inappropriate access to your Trusted IRIX/CMW workstation. The physical hardware of the Ethernet cable and the connection points between the workstations and the cable must be secured.
Many users assume that any number of separate physical computers connected via network cable defines a network. This, however, is not the case. A network is an uncontrolled data communication system, and not only can arbitrary and capricious information be encountered, but it must be expected.
The network under Trusted IRIX/CMW is a restricted system interconnect. The security of the system depends upon the proper use of the hardware and the software. The purpose of trusted networking is to properly label data that is imported or exported from the system, and to appropriately enforce the system security policy on that data.
For a more general discussion of networking theory and practice, the following books, available at any computer bookstore, are recommended:
Internetworking With TCP/IP—Principles, Protocols, and Architecture, by Douglas Comer, published by Prentice-Hall.
UNIX Network Programming, by W. Richard Stevens, published by Prentice-Hall.
Mandatory Access Control (MAC) is one of the primary means by which the system enforces your security policy. In order for your network to be trusted, the network must also support the mandatory access control rules of your security policy.
Not all sites may be homogeneous; that is, systems from different vendors may be on your trusted network, and perhaps not all are trusted multilevel systems. Yet all systems need to interoperate. The Trusted Security Information Exchange (TSIX) standard has been created to expand Internet Protocol (IP) support of MAC labels in a way that allows various vendors and trusted sites to interoperate.
Generally, unlabeled incoming packets will be labeled with the default label of the source host. Incoming labeled packets will be accepted only if within the label range of the source host. The packet label is then compared against the label of the target application.
For outgoing packets, the label of the sending application is compared against the range of the target host, and the packet will be sent only if the label falls within this range.
Under the TSIX system, labeling occurs at two levels:
At the network interface level, IP Security Options are used to label packets at the IP layer. There are several forms of IP Security Options, of which the most common are:
RIPSO (Revised Internet Protocol Security Option).
CIPSO (Commercial Internet Protocol Security Option). A received packet either has CIPSO or RIPSO options, or is unlabeled.
SGIPSO. This is another Security Option but it is not part of the TSIX standard.
At the CMW session manager level, Security Attribute Modulation Protocol (SAMP) and Security Attribute Token Mapping Protocol (SATMP) are used to send all the security attributes required to enforce security policy between network components. For more information about SAMP, see the samp(7P) man page.
The /etc/rhost.conf file is a database of information about the network security idioms used by all hosts in your trusted network. This database lists IP security options and session management attributes for each host and network. The rhost.conf file is described in more detail in “rhost.conf Database”.
In the case of CIPSO options, the sensitivity label is extracted, and if it is not within the label range of the interface it is dropped. In the case of an unlabeled packet, the sensitivity label is obtained from the default label of the interface if present, or from the host or network entry in the /etc/rhost.conf database. If the default label is not within the range of the interface, the packet is dropped.
The integrity portion of the label from the SGIPSO tag is used for the label range comparison. The default integrity for the host is used similar to the procedure for unlabeled packet processing.
For packets that are simply routed, or that require a reply from the TCP (such as Internet Control Message Protocol (ICMP) echo packets), the outgoing packets receive the same label as the incoming packets.
For TSIX hosts, the security attributes are provided in the SAMP header. Attributes identified as mandatory that are not present in the SAMP header are first supplied from the interface and then from the rhost.conf entry. If not all mandatory attributes are present, the packet is dropped in the case of User Datagram Protocol (UDP), or the connection is closed for TCP. The session manager maintains a composite set of attributes for the socket, which consists of the last modulated attributes and any defaults. These composite attributes are the attributes used to enforce policy on delivery to applications and are available to trusted applications through the TSIX application interface (API).
For UDP, SAMP attributes accompany each packet. For TCP, on initial connection the full set of attributes are exchanged before control is passed back to the application. If the attributes received from the remote host are not within the range of the user process, the connection is dropped with reset. A server process never sees the failed connection attempt, and the client sees the message connection closed by remote host.
The following sections deal with the steps involved in preparing a number of Trusted IRIX/CMW workstations to operate on a network. The possibilities in a heterogeneous environment are too numerous to document, but enough background is provided to instruct you in the necessary tasks that must be performed.
To create your Trusted IRIX/CMW network, you must first assemble your system and network hardware according to the instructions provided in the hardware package. Once the system is assembled, install your Trusted IRIX/CMW system distribution media on each system and you are ready to begin.
 | Tip: Your trusted network operates most smoothly if the security labels used on each system are the same, and have the same meanings, as those on every other system (that is, one set of labels for the network). This is achieved by ensuring that the /etc/mac file is consistent on all hosts in the network. Careful planning before you create your trusted systems is of great value when you create your network. |
Note that all network daemons, including nfsd and inetd, must be run at the same (or equivalent) labels on each system on your network. This is usually the administrative low label, dblow, on Trusted IRIX/CMW systems. If this is not the case, the daemons cannot find each other and communicate, and thus do not function properly. Label cognizant daemons such as nfsd and inetd enforce the MAC policy themselves, instead of relying on the operating system to enforce it for them, but all other network-related daemons (such as timed, routed, yp, and so on) are not label-cognizant and must always be interoperated at a single pre-defined label.
Some sites find that all systems on the network share the same set of labels (such as unclassified, confidential, secret, top secret, and so on) and while the relationship between the levels is the same, the integer values to represent them may be different. For example, the integer value of confidential is always less than the integer value of secret, but one system might have specified the secret label with an integer value of 3, and another may have used an integer value of 30 for the same secret label. This creates the need for software to interpret and equalize labels if all the systems do not share an identical label set.
Add to these situations the extra levels of specificity used to create MAC categories, and the process of defining the rules of translation for labels from different systems can become quite complex.
Labels transmitted on the network are tagged with a Domain of Interpretation (DOI). These tags tell each system how to map the bit representation of the incoming sensitivity label into the native bit representation.
As long as all systems in your network have the same native representation (they require no mapping), the network MAC policy works transparently. The network uses DOI 3 (which means native representation as determined by the local label database) and all packets with DOIs other than 3 are dropped.
All network services bear the restriction that the user must be cleared on the remote system at the label he or she is currently using on the local system. For example, if a user is logged in at the label usermiddle on a system and attempts to run the rlogin program on a remote system, the attempt cannot succeed unless the user is also cleared for the usermiddle label on the remote host. If the user's maximum clearance is userlow on the remote system, the rlogin attempt fails.
When using network services to log in to remote hosts, no provision is made for entering a label on the remote host. The user must conduct all transactions with the remote host at the current label on the local host. This restriction prevents writedown of data.
If you have a heterogeneous environment, the following steps should help you create an interoperating network . Trusted systems from different vendors are not likely to have the same feature sets, and those features that are similar in use may be implemented in radically different ways. Follow these steps:
Every system should keep DOI set to 3 (this is the default on Trusted IRIX/CMW systems).
Determine a set of labels and categories to use and their integer values.
Change all label databases to match the selected set of network labels. On your Trusted IRIX/CMW systems, edit the /etc/mac file.
Specify a default integrity label for the network. The incoming sensitivity label and the default integrity label are combined on each packet to create the MAC label that is used to enforce your security policy.
For more information on interoperating and trusted systems, see the trusted_networking(7) man page.
Trusted IRIX/CMW has significant differences from other trusted operating systems. One of these differences is the SGIPSO2 protocol . This protocol includes administrative labels, integrity labels, and user IDs. If you use a full Trusted IRIX/CMW label set, you can only fully make use of your label set with other Trusted IRIX/CMW systems.
The full label set is required by Trusted IRIX/CMW systems to enforce security policy in the evaluated configuration.
Trusted systems generally have a system high label—a label that dominates all other labels on the system, and a system low label—a label that is dominated by all other labels on the system. These labels are generally required for administrative activities. For example, when performing a system backup you must be logged in at the system high label. In trusted systems other than Trusted IRIX/CMW, these labels have to be calculated based on the configuration in the label database.
Trusted IRIX/CMW has implemented label types . There are label types for the high label, the low label, the auditor, and a type for ordinary labels. There is no mechanism except for the SGIPSO2 protocol for communication of administrative labels to non-Trusted IRIX/CMW systems. A similar issue is raised by using default integrity labels. The full range of labels that can be represented on a Trusted IRIX/CMW system cannot be communicated across the network. This is not an insurmountable problem, however, because if your users know what labels are cleared for network use, they can change their operating label to an acceptable label before using the network.
In order for a system to communicate with another host on your network:
The host must have an entry in the rhost.conf database. (Wildcard entries are permitted.)
The “next hop” host must have an entry in the rhost.conf database.
The packet must have a label within the range of all of the preceding conditions.
The rhost.conf database describes the MAC label interaction between your system and every other system on your trusted network. This database describes default labels to use for networking to non-trusted hosts and the idiom of network label support used for trusted multilabel hosts. All information relevant to trusted networking for each host on your network is stored in this file on each system. You must manually enter each host in your trusted network in your rhost.conf file, along with the idiom of label support used by that host.
To create your rhost.conf database, take the sample /etc/rhost.conf file distributed with Trusted IRIX/CMW and edit it, adding each host's entry individually.
The following sections describe the syntax of the rhost.conf file:
Templates in rhost.conf
Individual host entries in rhost.conf
Wildcard entries in rhost.conf
The information at the top of the rhost.conf file specifies templates for hosts that fulfill certain common requirements for label interchange. The syntax allows you to create custom host templates as well. At the bottom of the rhost.conf file, an entry that is similar to the following specifies a previously defined template (in this case, default_sgipso, which is reprinted in the following template):
Hostname: default_spec = default_sgipso: |
If you have planned your trusted network well, using a common set of labels, you should be able to use the provided templates as distributed for your hosts. Several templates are provided for commonly used labeling idioms.
The following template is reprinted here as an example:
################################################################ # Default SGI IP Security Extension ################################################################ default_sgipso_userlow\ smm_type = single_level:\ nlm_type = sgipso:\ def_sl = msentcsec,unclassified:\ def_integ = mintbiba,lowestgrade:\ default_spec = .: |
A specific host entry in an rhost.conf file follows the same syntax as a template entry, and can either specify all attributes, or use some combination of a template and an individual specification. For example:
anewhost:\ default_spec = default_tsix_1_0:\ min_sl = confidential:\ max_sl = secret: |
This example uses a template to describe most attributes, and the minimum and maximum label are specified for the host.
All interfaces on the host should be specified and consistent, including the localhost. For example, if the host was called fred, then the rhost.conf file must include entries for fred and localhost. For example:
######################################################## # Always put local workstation/server name and localhost ######################################################## fred: default_spec = default_samp_userlow: localhost: default_spec = default_samp_userlow: |
The following examples show how individual hosts may be specified using templates. Note that hosts may be specified by name or by IP address. Also, note that the second entry is a wildcard entry, which is described in “Wildcard Entries in rhost.conf”.
| pender: | default_spec = default_sgipso: | |
| 154.16.0.0: | default_spec = default_single_level: | |
| 192.88.83.26: | default_spec = default_single_level: | |
| howard: | default_spec = default_tsig: | |
| hancock: | default_spec = default_cipso: |
A wildcard entry is an IP address with zeros in some positions. For example, consider the following IP format addresses from an rhost.conf file:
128.01.01.0: 128.01.0.0: 128.0.0.0 0.0.0.0: |
All these are wildcard entries with increasing scope as you move down the list. When looking up a specific network address in response to a user command, a system must first search for the whole address, and then successively withdraw a byte and look for a wildcard match. This allows the following strategy to work: Consider that a user has requested a file transfer from a specific host. The operating system must determine what label interchange arrangement exists with that host, so it begins by looking up the host's entry in the rhost.conf database. The IP address being searched for is 128.01.01.01. The rhost.conf database could hold any of the following entries:
| 128.01.01.01: | This is the host that is needed. Use its specific entry from the database. | |
| 128.01.01.0: | This entire subnetwork is defined to use a single entry from the database (partial wildcard entry). | |
| 0.0.0.0: | The whole network is untrusted and is communicated with only at the default label (100% wildcard entry). |
The rhost command, without any options, loads the default configuration file, /etc/rhost.conf, into your kernel for use by the network. The following options are available to the rhost command:
| -l hostname | Displays the characteristics of the current host | |
| -f filename | Loads an alternate file into the kernel. |
You can create an interoperating heterogeneous network with a limited label set, but if you wish to make full use of Trusted IRIX/CMW features, such as the windowing system and shared filesystems, you must use the full set of security attributes to appropriately enforce the security policy of the system.
The TSIX standard is a specification of a session layer protocol for passing all attributes needed to completely enforce security policy between two systems. There is a set of attributes that may be necessary, depending on your security policy, to enforce your policy. The communicating hosts may agree to send all, some, or none of the security attributes from the following set:
Sensitivity label
Nationality caveats
Integrity label
TSIX session ID
Clearance
Process Access Control List
Information label
Capability set
Login (audit) ID
Process ID
Discretionary ID
Additional client audit info
Process attributes
The protocol used to communicate the attributes between systems is SAMP. This is a header and a list of attributes that is prepended to outgoing data as if it were user data. The TOE at each end of the connection has to put this information on, and pull it off and use it before the “real” data is passed to the user program.
Under Trusted IRIX/CMW, each attribute is represented in ASCII form. The ASCII representation is the same as your label name, for example, TOP SECRET. User and Group ID numbers are also an ASCII user or group name. Each attribute has its own defined formats in the SAMP standard.
Trusted IRIX/CMW converts the ASCII representations to a 32-bit token that is prepended to the packet for transfer. The SATMP protocol defines these tokens.
When two systems with session management communicate over the network, they first perform a SATMP handshake. During this handshake, the two systems negotiate which predefined Domain of Translation (DOT) they have in common for each required attribute in the SAMP protocol. Your rhost.conf database specifies which attributes are required of the remote host, and what defaults may be substituted if the remote host cannot supply a particular attribute. Your DOT are established as you build your network's rhost.conf database.
The remote host database also allows the system to distinguish which hosts it can use TSIX to communicate with, which have only IP Options (such as CIPSO), which are unlabeled, and what level of trust to give each type of host. For example, you can specify that your system communicate with unlabeled hosts, but for purposes of enforcing policy, treat all communication as if it is unclassified, low integrity, and the user is guest with no capabilities. This specification happens in the rhost.conf file.
If the two hosts attempting to communicate cannot find a common DOT for each attribute or supply appropriate defaults, no communication happens. This protects system security.
A well-planned network implements user ID and group ID numbers centrally, so that they are identical across the entire network. If this is the case, these numbers need not be mapped. Similarly, capabilities and labels should also be identical across your network.
Within an organization of Trusted IRIX/CMW systems and users, there may exist different subgroups of users and systems that use different sets of label hierarchies and categories. For example, one group may have sensitivity levels that are named Unclassified, Confidential, Secret, and Top Secret and categories named after military weapons systems, while another group may have sensitivity levels called Public, Company Confidential, Management Only, Directors Only, and CEO Only, and may have categories named Payroll, Hardware Engineering, and OS Software.
In a heterogeneous environment, you have several options:
Hosts can be unlabeled. Security attributes are implied by the default definition in the rhost.conf file.
Hosts may have IP security options only, such as CIPSO. In this case the sensitivity label is described by the Domain of Interpretation. There is also a Trusted IRIX/CMW IP option that sends integrity label and user id number information.
Hosts may be TSIX hosts. In this case the host supports sending any of the standard list of attributes.
Not all attributes are supported on all systems. Missing attributes are implied by the use of defaults by the receiving host.
There is one DOT for each security attribute, and the DOT describes the interpretation of the attribute. In the case of sensitivity labels a DOT is a mapping similar in concept to the Domain of Interpretation.
A DOT means other things for other attributes. The account called darius on one system can be matched to dcouch on another. User ID numbers and group ID numbers usually are not mapped, because large installations usually ensure that user ID numbers are identical on all systems.
The other special case is capabilities. These are usually vendor specific mappings in a heterogeneous environment. Because the implementation of privilege is highly variable, mappings are frequently difficult or impossible, and best left to defaults.
Trusted IRIX/CMW implements only one Domain of Interpretation (DOI), DOI 3, but multiple DOTs between TSIX-supporting hosts. The mapping tables for the single DOI are identical to the contents of the files in the directory /etc/mac_label. Because Trusted IRIX/CMW supports only one DOI, the same DOI identification number should be used on all CIPSO and SGIPSO interfaces.
If systems in different groups use the same category and level names but have different number values for these names, label confusion can occur. For example, consider Table 4-1:
Label Name | Group A Number | Group B Number |
|---|---|---|
Unclassified | 0 | 10 |
Confidential | 10 | 20 |
Secret | 20 | 30 |
Top Secret | 30 | 40 |
Obviously, if the computers of these two groups were to begin to interoperate (for example, a gateway was added between their respective networks), then a computer in group A could send Secret data with the number 20, and when it arrived at a group B computer it is understood as Confidential data. This communication causes a writedown (downgrading) of that data. This type of situation is expressly prohibited for trusted systems.
Continuing the example, consider a group C, which uses the names Public, Company Confidential, and so on according to Table 4-2. If this group adds a gateway to group A, there is a label mismatch. Table 4-2 depicts the mismatch:
Number | Group A Name | Group C Name |
|---|---|---|
0 | Unclassified | Public |
10 | Confidential | Company Confidential |
20 | Secret | Management only |
30 | Top Secret | Directors only |
There is a mismatch problem if these two groups begin to interpret the numbers coming from the other system according to their own tables. Although there is a surface similarity between the numbers used to represent the labels, neither group wants its top-level information to be available to the other group. For more information on label dominance, see the dominance(5) man page.
There may also be an overlapping situation, where some systems are able and cleared to understand multiple sets of information. For example, consider a computer that is allowed to use information according to the following hierarchy. This system is able to receive and send data securely among groups A, B, and C:
Public |
Unclassified Company Confidential Confidential Management Only Secret Directors Only Top Secret CEO only |
To avoid writedown or overlapping, each group must have a set of mapping tables (one for sensitivity level, one for sensitivity category, one for each integrity grade and one for each integrity division). This set of tables facilitates the translation of label names onto numeric values and conversely of number values onto label names. Any such set of tables may be called a map.
Under Trusted IRIX/CMW, the actual map tables are placed into the file /etc/mac. The netif.options is a good place to put the DOI identification numbers.
Most of the network services offered by a host system are offered through a program called inetd. This daemon is run automatically during system startup if the network has been turned on with the chkconfig command. The specific command used is
chkconfig network on |
Rather than having each system service run continuously, inetd offers the services of these daemons on their behalf. When a request for one of the offered services arrives and is received by inetd, it spawns a child process according to the service requests (for example, inetd spawns rlogind for an rlogin request).
Typically, each new request for a particular service results in a new instance of the daemon that provides that service being spawned. That daemon remains in execution for the duration of the request and then terminates.
The Trusted IRIX/CMW version of inetd offers a special service . It can offer any of its services at all labels. The inetd daemon can receive requests for any service at any label. Under Trusted IRIX/CMW, inetd can, for example, receive rlogin requests at any label from dblow to msenhigh/mintlow, and inetd spawns the appropriate daemon at a label matching that of the incoming request. Because of this service, most programs that run as spawned children of inetd do not have to be modified in any way to understand labels; they do not have to be made “label cognizant.” These programs, running as children of inetd, are invoked at the correct label in each instance by inetd.
Although they do not have to be made label cognizant, most of the child processes of inetd run as root, and have root access to the privilege of programs. All programs run by inetd must be within the TOE. The fact that a program or file is part of the TOE is signified to inetd by the program or file bearing the dblow label. The inetd daemon cannot (due to MAC) spawn a child process unless the program file for the process is labeled dblow. For example, the file /usr/bsd/rlogind is labeled dblow, so it can be run by inetd.
If a system administrator takes untrustworthy software, such as programs taken from other source bases or from other operating systems (for example, standard IRIX) and labels it dblow, thereby making it a part of the TOE, that system administrator is violating the integrity of the TOE and can open the system to security violations.
Not all network services are offered by inetd. Several notable exceptions are the portmap service offered by the portmap program, NFS, the X Window server, and sendmail. The sendmail and portmap services have been made label cognizant and offer services to clients at all labels. NFS uses the nfsd and biod servers. These are kernel processes and as such they are also a label-cognizant part of the Trusted IRIX/CMW kernel.
The following sections contain information useful to the administrator of a trusted network:
The /etc/hosts.equiv and $HOME/.rhosts files
Maintaining the system audit trail
NFS under Trusted IRIX/CMW
Using electronic mail
Under Trusted IRIX/CMW, only the first field of the /etc/hosts.equiv and $HOME/.rhosts files is relevant to the system. The second field in both files is ignored. This behavior places a restriction on the rsh and rlogin programs, which do not allow unchallenged access (access without demanding a password) unless the remote user name and user ID are exactly identical to the local user name and user ID. In addition, the label of the shell on the local system must match the default label for the user account on the remote system. If a different name or user ID is used, the user is prompted for a password that authenticates the user's identity in the usual manner.
The MAC label of the $HOME/.rhosts file must be dominated by the MAC label of the login session, otherwise the user will be prompted for a password. It is recommended that the $HOME/.rhosts file be labeled such that it is dominated by all other labels with which the user can log in to the system.
For a network of several workstations, the audit trail can accumulate a considerable amount of data. The current estimate of audit information is that if all auditing is enabled, a typical workstation can expect to generate 10,000 bytes per second of audit information. Most systems are not able to store this information adequately on the computer's hard disk for a great length of time. It is imperative that a multi-workstation Trusted IRIX/CMW network have a secure and thorough electronic backup plan.
It is also imperative that the individual systems keep their system clocks synchronized. This is accomplished with the timed daemon. One system is the designated master time server. All the other systems on the network synchronize their clocks with the server.
The reason that individual stations must keep their clocks synchronized is so that the combined system audit trail is accurate. If attempts to compromise system security are happening, the auditor needs to know the exact sequence of events on each system, with respect to every other system on the network. The way to maintain order in the audit logs is by running timed.
Complete information on running timed is found in the timed(1M) man page.
Trusted IRIX/CMW provides full support for the NFS version 3 filesystem-sharing software. NFS is an optional software product. For a complete discussion of NFS, see your standard IRIX NFS documentation.
The base NFS protocol does not support MAC labels, ACLs, or capability sets on files. ACL support is an installation option for NFS under Trusted IRIX/CMW. This information is transferred using an extension to NFS called the Extended Attribute protocol. The mount(1) man page describes how to mount filesystems using NFS.
Electronic mail service is provided under Trusted IRIX/CMW. There are some restrictions, however, to the use of mail.
As with all other data objects on the system, electronic mail is labeled. When someone sends mail, the mail message inherits the current label of the sender. According to the rules governing Mandatory Access Control (MAC), the recipient of the mail must be running at a correspondingly equal label to read the mail sent. If the recipient is running at a different label, he or she must change to an appropriate label to be able to read the mail. If the sender is running at a label different to the label of the recipient, the recipient cannot read the mail or even be notified of its existence until he or she logs in at or changes to the label that the mail is at.
MAC protection extends into replying to mail as well as reading it. If the recipient responds to the mail, it will be of the same label as the one associated with the mail received. This policy prevents accidental "writedown" of information from a higher label to a lower label.
To send mail across a gateway onto an unlabeled network, a user must send the mail at the assigned label for the unlabeled network. All mail traffic arriving from an unlabeled network is labeled with the label assigned to that network.
The mail system is driven on each system by a daemon program called sendmail. The sendmail program is a mail routing clearinghouse. When you use your preferred mailer, such as Mail, sendmail takes the message you have created and prepares it for the destination system. Then sendmail calls the appropriate utilities to deliver the mail locally or queues it for transmission. The sendmail daemon has been made label cognizant for Trusted IRIX/CMW. For more general discussion of sendmail, refer to IRIX Admin: Networking and Mail .