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.
A central concept to the Silicon Graphics 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. The heart of the Trusted IRIX/CMW multiple workstation system is the network. 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 rubricator 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 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 in fact a critical part of each system's TCB and as such 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 coaxial 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 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.
It is recognized that not all sites are homogeneous, that is to say, systems may be on your trusted network from different vendors, and perhaps not all are trusted multi-level systems. Yet all systems need to interoperate. The TSIX standard has been created to expand IP support of MAC labels in a way that allows various vendors and trusted sites to interoperate with one another.
Under the TSIX system, labeling occurs at two levels:
At the network interface level, IP Security Options are used to route traffic. There are several forms of IP Security Options, of which the most common are RIPSO (Revised Internet Protocol Security Option) and CIPSO (Commercial Internet Protocol Security Option). A received packet either has CIPSO or RIPSO options, or is unlabeled.
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.
An integrity label range may be specified for the network interface. If an integrity range is present, the integrity portion of the label from the SGIPSO tag is used for the label range comparison; otherwise, the default integrity for either the interface or host is used similar to the procedure for unlabeled packet processing.
For packets that are simply routed, or that require a reply from the TCB (such as ICMP echo packets), the outgoing packets receive the same label as the incoming packets. That label is used for a label range check against the outgoing interface, and the packet is dropped if it is not within range.
For TSIX hosts, the IP header label is no longer used for policy. For unlabeled hosts, and for non-TSIX hosts the IP label is used for any further policy decisions.
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 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. The /etc/rhost.conf file is a database of information about the network security idioms used by all hosts in your trusted network. If all mandatory attributes are not present, the packet is dropped in the case of UDP, or the connection is closed for TCP. The session manager maintains a composite set of attributes for the socket that 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 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 policies enforced by trusted networking are as follows:
Received packets must be within the label range of the interface and the host or network.
Delivered data must have a label dominated by the receiving process. The UID of the delivered data must be permitted by the socket ACL.
Trusted processes that have set the extended attributes mode do not have delivery policy enforced, but must themselves enforce appropriate policy.
The sections below 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.
 | Caution: 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. Careful planning before you create your trusted systems is of great value when you create your network. |
Note that all network daemons, including nfsd(1M) and inetd(1M), 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.
Under Trusted IRIX/CMW, the native bit representation is established with the mklbldb(1M) program that builds the label database. This database also maintains the mapping of each symbolic label name to its integer level and categories.
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 – taken to mean 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 execute the rlogin(1) 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 set DOI to 3.
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_label/levelnames file and rebuild the database with mklbldb.
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, read the material provided on the TSIG (Trusted Systems Interoperability Group) site on the World Wide Web. (http://ftp.sterling.com/tsig)
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 UIDs. 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 interface must be labeled using the iflabel(1) command.
The packet must have a label within the range of all of the above 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 multi-label 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.
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 reads similarly to this:
Hostname: default_spec = default_sgipso: |
is specifying a previously defined template. (In this case, default_sgipso, which is reprinted below.)
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:
################################################################ # SGIPSO2 Trix5.3/4.0.5 Hosts # ################################################################ default_sgipso: nlm_type = sgipso2:\ smm_type = single_level:\ doi = cipso_tsig:\ default_spec = .:\ max_privs = CAP_CHOWN,CAP_SETGID,CAP_SETUID,CAP_DAC_EXECUTE+eip:\ cache_size = 512:\ flags = mand_sl,import,export:\ def_privs = CAP_CHOWN,CAP_SETGID,CAP_SETUID,CAP_DAC_EXECUTE+eip:\ def_luid = root:\ def_uid = root:\ def_gid = root:\ def_ngrps = 1:\ def_gids = sys:\ def_sid = 0:\ def_sl = userlow:\ def_clearance = userlow:\ def_ilb = userlow:\ min_sl = userlow:\ max_sl = userlow: |
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:
# 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.
The localhost must always be specified as well:
# Always put host and localhost host: default_spec = default_tsig: localhost: default_spec = default_tsig: |
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 the second entry is a wildcard entry, which is described below:
| 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 | Load an alternate file into the kernel. |
The syntax of the input file is modeled after the rhost.conf database description found on the TSIG site on the World Wide Web. (http://ftp.sterling.com/tsig)
The iflabel(1) command is used to assign a specific set of trusted networking rules (called an idiom) to a network interface and to configure the network interface label parameters. This is done because trusted networking requires that all packets sent over the network must retain their security classifications and other attributes, unless specific policy is in place. Because your trusted system may be in heterogeneous operation with other trusted and untrusted systems, several idioms of network labeling are allowed to maximize interoperability.
For complete information on the use and parameters of iflabel, see the iflabel(1) reference page.
The iflabel command is invoked at boot time from /etc/rc2.d/network to define the label exchange idiom of each network interface present on the system; you may also use it once the system is running to redefine an interface's idiom or other label parameters. However, it is generally considered good system administration practice to change the iflabel configuration file and then to reboot the system in order to change the idiom of a network interface. There is one configuration file, called /etc/config/iflabel-?.options for each network interface on your system. The actual file names replace the question mark with the code for the particular interface, for example, ec0. Use the netstat -i command to list your system's network interfaces.
Only the Superuser may modify the configuration of a network interface. The iflabel command may be invoked with any of several idioms, or with none at all. If iflabel is invoked with no idiom or label parameters, it displays the current idiom for the specified network interface and the current values of the parameters appropriate to that idiom.
The iflabel command may be invoked with any one of these idioms:
| MONO | This idiom is used when a trusted multi-level host (such as a Trusted IRIX/CMW system) is attached to a single level (possibly untrusted) network. Datagrams sent between hosts on a single level network do not contain labels in their IP option subheader; all traffic on a single level network is defined to take place at the label of the network. | |
| BSO | All network traffic over a BSO interface must be at a label dominated by the highest label of the network interface and dominating the lowest label of the interface. | |
| BSO_TX | This idiom is precisely like BSO except that labels are always transmitted with outgoing datagrams but not required on incoming datagrams. | |
| CIPSO2 | All network traffic over a CIPSO2 interface must be at a label dominated by the highest label of the interface and dominating the lowest label of the interface. | |
| SGIPSO2 | This idiom, an extension to CIPSO2, provides a mechanism to attach to all network traffic, a complete SGI MAC (mandatory access control) label, along with the User ID of the sending process. Besides a sensitivity level and a category set, the MAC label may include integrity components and label types other than TCSEC, EXACT, and BIBA. |
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 file systems, 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 (ACL)
Information label
Privilege (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 TCB at each end of the connection has to put this information on, and pull it off and use it before the “real” data gets 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 communicate over the network, they first perform a SATMP handshake. During this handshake, the two systems negotiate which predefined Domain of Translation 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 Domains of Translation 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), and which are unlabeled, and what level of trust to give each type of host. For example, you can specify that your system communicates with unlabeled hosts, but for purposes of enforcing policy, treats 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 can not find a common DOT for each attribute or supply appropriate defaults, no communication happens. This protects system security.
A well-planned network implements UID and GID 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. UID numbers and GID numbers usually are not mapped since large installations usually ensure that User ID numbers are identical on all systems.
The other special case is privileges or capabilities. These are usually vendor specific mappings in a heterogeneous environment. Because the implementation of privileges and capabilities is highly variable, mappings are frequently difficult or impossible, and best left to defaults.
Trusted IRIX/CMW implements only one 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. The DOI identification number is specified for each interface using the iflabel(1) program. Since 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 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) reference 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 files named levelnames, categorynames, gradenames, and divisionnames, in the directory /etc/mac_label. The DOI identification numbers are configured onto the interfaces using the iflabel(1) program. For convenience, the file /etc/config/netif.options contains the iflabel commands that are routinely run at system start-up. 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 access to the privileges of root programs. All programs run by inetd must be within the TCB. The fact that a program or file is part of the TCB 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 (such as standard IRIX) and labels them dblow, thereby making them a part of the TCB, that System Administrator is violating the integrity of the TCB 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.
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 is ignored as a comment. This behavior places a restriction on the rsh(1) and rlogin(1) programs, which do not allow unchallenged access (access without demanding a password) unless the remote user name and UID are exactly identical to the local user name and UID. If a different name or UID is used, the user is prompted for a password that authenticates the user's identity in the usual manner.
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(1M) 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) reference 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. This information is transferred over the trusted network using SAMP and SATMP as with any other network traffic, as described above. The mount(1) reference 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 sender's current label. According to the rules governing Mandatory Access Control, the recipient of the mail must be running at a correspondingly equal or dominant label to read the mail sent. If the recipient is running at a lower label, he or she must change labels to an appropriate label to be able to read the mail. If the sender is running at a label dominating the recipient's maximum label, the recipient cannot read the mail or even be notified of its existence until his or her available labels are expanded to include the label of the mail.
MAC protection extends into replying to mail as well as reading it. If someone receives a message from a user at a lower label, the recipient is able to read the mail, but if the recipient responds to the mail, the system attaches the higher label of the recipient to the response. If the original sender is not cleared for the recipient's label, he or she cannot read the response. This policy prevents accidental “writedown” of information from the higher label to a lower label.
To send mail across a gateway onto a 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, of course, 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(1), 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 .