Part II Administration of Trusted Extensions

This section describes how to administer Trusted Extensions.

Chapter 7, Trusted Extensions Administration Concepts introduces you to Trusted Extensions software.

Chapter 8, Trusted Extensions Administration Tools describes the administrative programs that are specific to Trusted Extensions software.

Chapter 9, Getting Started as a Trusted Extensions Administrator (Tasks) introduces the administrator to Trusted Extensions. This chapter also describes the new features in this release.

Chapter 10, Security Requirements on a Trusted Extensions System (Overview) describes the .

Chapter 11, Administering Security Requirements in Trusted Extensions (Tasks) describes common tasks when administering Trusted Extensions.

Chapter 12, Users, Rights, and Roles in Trusted Extensions (Overview) introduces RBAC for Trusted Extensions.

Chapter 13, Managing Users, Rights, and Roles in Trusted Extensions (Tasks) provides instructions on managing regular users of Trusted Extensions.

Chapter 14, Remote Administration in Trusted Extensions (Tasks) provides instructions on administering Trusted Extensions remotely.

Chapter 15, Trusted Extensions and LDAP (Overview) provides instructions on administering LDAP for Trusted Extensions.

Chapter 16, Managing Zones in Trusted Extensions (Tasks) provides instructions on managing labeled zones.

Chapter 17, Managing and Mounting Files in Trusted Extensions (Tasks) provides instructions on managing mounting, backing up the system, and other file-related tasks in Trusted Extensions.

Chapter 18, Trusted Networking (Overview) provides an overview of the network databases and routing in Trusted Extensions.

Chapter 19, Managing Networks in Trusted Extensions (Tasks) provides instructions on managing the network databases and routing in Trusted Extensions.

Chapter 20, Multilevel Mail in Trusted Extensions (Overview) describes mail-specific issues in Trusted Extensions.

Chapter 21, Managing Labeled Printing (Tasks) provides instructions on handling printing in Trusted Extensions.

Chapter 23, Managing Devices for Trusted Extensions (Tasks) provides instructions on managing devices by using the Device Allocation Manager.

Chapter 24, Trusted Extensions Auditing (Overview) provides Trusted Extensions–specific information about auditing.

Chapter 25, Software Management in Trusted Extensions (Tasks) describes how to administer programs on a Trusted Extensions system.

Chapter 7 Trusted Extensions Administration Concepts

This chapter introduces you to administering a system that is configured with Solaris^TM Trusted Extensions software.

• Trusted Extensions Software and the Solaris OS

• Basic Concepts of Trusted Extensions

Trusted Extensions Software and the Solaris OS

Trusted Extensions software adds labels to a system that is running the Solaris Operating System (Solaris OS). Labels implement mandatory access control (MAC). MAC, along with discretionary access control (DAC), protects system subjects (processes) and objects (data). Trusted Extensions software provides interfaces to handle label configuration, label assignment, and label policy.

Similarities Between Trusted Extensions and the Solaris OS

Trusted Extensions software uses rights profiles, roles, auditing, privileges, and other security features of the Solaris OS. You can use Solaris Secure Shell (SSH), BART, the Solaris cryptographic framework, IPsec, and IPfilter with Trusted Extensions.

• As in the Solaris OS, users can be limited to using applications that are necessary for performing their jobs. Other users can be authorized to do more.

• As in the Solaris OS, capabilities that were formerly assigned to superuser are assigned to separate, discrete “roles.”

• As in the Solaris OS, privileges protect processes. Zones are also used to separate processes.

• As in the Solaris OS, events on the system can be audited.

• Trusted Extensions uses the system configuration files of the Solaris OS, such as policy.conf and exec_attr.

Differences Between Trusted Extensions and the Solaris OS

Trusted Extensions software extends the Solaris OS. The following list provides an overview. For a quick reference, see Appendix C, Quick Reference to Trusted Extensions Administration.

• Trusted Extensions controls access to data with special security tags that are called labels. Labels provide mandatory access control (MAC). MAC protection is in addition to UNIX® file permissions, or discretionary access control (DAC). Labels are directly assigned to users, zones, devices, windows, and network endpoints. Labels are implicitly assigned to processes, files, and other system objects.

  MAC cannot be overridden by regular users. Trusted Extensions requires regular users to operate in labeled zones. By default, no users or processes in labeled zones can override MAC.

  As in the Solaris OS, the ability to override security policy can be assigned to specific processes or users when MAC can be overridden. For example, users can be authorized to change the label of a file. Such an action upgrades or downgrades the sensitivity of the information in that file.

• Trusted Extensions adds to existing configuration files and commands. For example, Trusted Extensions adds audit events, authorizations, privileges, and rights profiles.

• Some features that are optional on a Solaris system are required on a Trusted Extensions system. For example, zones and roles are required on a system that is configured with Trusted Extensions.

• Some features that are optional on a Solaris system are recommended on a Trusted Extensions system. For example, in Trusted Extensions the root user should be turned into the root role.

• Trusted Extensions can change the default behavior of the Solaris OS. For example, on a system that is configured with Trusted Extensions, auditing is enabled by default. In addition, device allocation is required.

• Trusted Extensions can narrow the options that are available in the Solaris OS. For example, on a system that is configured with Trusted Extensions, the NIS+ naming service is not supported. Also, in Trusted Extensions, all zones are labeled zones. Unlike the Solaris OS, labeled zones must use the same pool of user IDs and group IDs. Additionally, in Trusted Extensions, labeled zones can share one IP address.

• Trusted Extensions provides a trusted version of the GNOME desktop, Solaris Trusted Extensions (GNOME). The name can be shortened to Trusted GNOME.

• Trusted Extensions provides additional graphical user interfaces (GUIs) and command line interfaces (CLIs). For example, Trusted Extensions provides the Device Allocation Manager to administer devices. In addition, the updatehome command is used to place startup files in an regular user's home directory at every label.

• Trusted Extensions requires the use of particular GUIs for administration. For example, on a system that is configured with Trusted Extensions, the Solaris Management Console is used to administer users, roles, and the network.

• Trusted Extensions limits what users can see. For example, a device that cannot be allocated by a user cannot be seen by that user.

• Trusted Extensions limits users' desktop options. For example, users are allowed a limited time of workstation inactivity before the screen locks.

Multiheaded Systems and the Trusted Extensions Desktop

When the monitors of a multiheaded Trusted Extensions system are configured horizontally, the trusted stripe stretches across the monitors. When the monitors are configured vertically, the trusted stripe appears in the lowest monitor.

When different workspaces are displayed on the monitors of a multiheaded system, Trusted GNOME displays a trusted stripe on each monitor.

Basic Concepts of Trusted Extensions

Trusted Extensions software adds labels to a Solaris system. Labeled desktops and trusted applications, such as the Label Builder and the Device Allocation Manager, are also added. The concepts in this section are necessary to understand Trusted Extensions, both for users and administrators. Users are introduced to these concepts in the Solaris Trusted Extensions User’s Guide.

Trusted Extensions Protections

Trusted Extensions software enhances the protection of the Solaris OS. The Solaris OS protects access to the system with user accounts that require passwords. You can require that passwords be changed regularly, be of a certain length, and so on. Roles require additional passwords to perform administrative tasks. Additional authentication limits the damage that can be done by an intruder who guesses the root password, because roles cannot be used as login accounts. Trusted Extensions software goes further by restricting users and roles to an approved label range. This label range limits the information that users and roles can access.

Trusted Extensions software displays the Trusted Path symbol, an unmistakable, tamper-proof emblem that appears at the left of the trusted stripe. In Trusted GNOME, the stripe is at the top of the screen. The Trusted Path symbol indicates to users when they are using security-related parts of the system. If this symbol does not appear when the user is running a trusted application, that version of the application should be checked immediately for authenticity. If the trusted stripe does not appear, the desktop is not trustworthy. For a sample desktop display, see Figure 7–1.

Figure 7–1 Trusted Extensions Multilevel CDE Desktop

Most security-related software, that is, the Trusted Computing Base (TCB), runs in the global zone. Regular users cannot enter the global zone or view its resources. Users are able to interact with TCB software, as in when they change passwords. The Trusted Path symbol is displayed whenever the user interacts with the TCB.

Trusted Extensions and Access Control

Trusted Extensions software protects information and other resources through both discretionary access control (DAC) and mandatory access control (MAC). DAC is the traditional UNIX permission bits and access control lists that are set at the discretion of the owner. MAC is a mechanism that the system enforces automatically. MAC controls all transactions by checking the labels of processes and data in the transaction.

A user's label represents the sensitivity level at which the user is permitted to operate and chooses to operate. Typical labels are Secret, or Public. The label determines the information that the user is allowed to access. Both MAC and DAC can be overridden by special permissions that are in the Solaris OS. Privileges are special permissions that can be granted to processes. Authorizations are special permissions that can be granted to users and roles by an administrator.

As an administrator, you need to train users on the proper procedures for securing their files and directories, according to your site's security policy. Furthermore, you need to instruct any users who are allowed to upgrade or downgrade labels as to when doing so is appropriate.

Roles and Trusted Extensions

On a system that is running Solaris software without Trusted Extensions, roles are optional. On a system that is configured with Trusted Extensions, roles are required. The system is administered by the System Administrator role and the Security Administrator role. In some cases, the root role is used.

As in the Solaris OS, rights profiles are the basis of a role's capabilities. Trusted Extensions provides two rights profiles, Information Security and User Security. These two profiles define the Security Administrator role.

The programs that are available to a role in Trusted Extensions have a special property, the trusted path attribute. This attribute indicates that the program is part of the TCB. The trusted path attribute is available when a program is launched from the global zone.

For information about roles, see Part III, Roles, Rights Profiles, and Privileges, in System Administration Guide: Security Services.

Labels in Trusted Extensions Software

Labels and clearances are at the center of mandatory access control (MAC) in Trusted Extensions. They determine which users can access which programs, files, and directories. Labels and clearances consist of one classification component and zero or more compartment components. The classification component indicates a hierarchical level of security such as TOP SECRET or CONFIDENTIAL. The compartment component represents a group of users who might need access to a common body of information. Some typical types of compartments are projects, departments, or physical locations. Labels are readable by authorized users, but internally, labels are manipulated as numbers. The numbers and their readable versions are defined in the label_encodings file.

Trusted Extensions mediates all attempted security-related transactions. The software compares the labels of the accessing entity, typically a process, and the entity being accessed, usually a filesystem object. The software then permits or disallows the transaction depending on which label is dominant. Labels are also used to determine access to other system resources, such as allocatable devices, networks, frame buffers, and other hosts.

Dominance Relationships Between Labels

One entity's label is said to dominate another label if the following two conditions are met:

• The classification component of the first entity's label is equal to or higher than the second entity's classification. The security administrator assigns numbers to classifications in the label_encodings file. The software compares these numbers to determine dominance.

• The set of compartments in the first entity includes all of the second entity's compartments.

Two labels are said to be equal if they have the same classification and the same set of compartments. If the labels are equal, they dominate each other and access is permitted.

If one label has a higher classification or if it has the same classification and its compartments are a superset of the second label's compartments, or both, the first label is said to strictly dominate the second label.

Two labels are said to be disjoint or noncomparable if neither label dominates the other label.

The following table presents examples of label comparisons for dominance. In the example, NEED_TO_KNOW is a higher classification than INTERNAL. There are three compartments: Eng, Mkt, and Fin.

Administrative Labels

Trusted Extensions provides two special administrative labels that are used as labels or clearances: ADMIN_HIGH and ADMIN_LOW. These labels are used to protect system resources and are intended for administrators rather than regular users.

ADMIN_HIGH is the highest label. ADMIN_HIGH dominates all other labels in the system and is used to protect system data, such as administration databases or audit trails, from being read. You must be in the global zone to read data that is labeled ADMIN_HIGH.

ADMIN_LOW is the lowest label. ADMIN_LOW is dominated by all other labels in a system, including labels for regular users. Mandatory access control does not permit users to write data to files with labels lower than the user's label. Thus, a file at the label ADMIN_LOW can be read by regular users, but cannot be modified. ADMIN_LOW is typically used to protect public executables that are shared, such as files in /usr/bin.

Label Encodings File

All label components for a system, that is, classifications, compartments, and the associated rules, are stored in an ADMIN_HIGH file, the label_encodings file. This file is located in the /etc/security/tsol directory. The security administrator sets up the label_encodings file for the site. A label encodings file contains:

• Component definitions – Definitions of classifications, compartments, labels, and clearances, including rules for required combinations and constraints

• Accreditation range definitions – Specification of the clearances and minimum labels that define the sets of available labels for the entire system and for regular users

• Printing specifications – Identification and handling information for print banners, trailers, headers, footers, and other security features on printer output

• Customizations – Local definitions including label color codes, and other defaults

For more information, see the label_encodings(4) man page. Detailed information can also be found in Solaris Trusted Extensions Label Administration and Compartmented Mode Workstation Labeling: Encodings Format.

Label Ranges

A label range is the set of potentially usable labels at which users can operate. Both users and resources both have label ranges. Resources that can be protected by label ranges include such things as allocatable devices, networks, interfaces, frame buffers, and commands. A label range is defined by a clearance at the top of the range and a minimum label at the bottom.

A range does not necessarily include all combinations of labels that fall between a maximum and minimum label. Rules in the label_encodings file can disqualify certain combinations. A label must be well-formed, that is, permitted by all applicable rules in the label encodings file, in order to be included in a range.

However, a clearance does not have to be well-formed. Suppose, for example, that a label_encodings file prohibits any combination of compartments Eng, Mkt, and Fin in a label. INTERNAL Eng Mkt Fin would be a valid clearance but not a valid label. As a clearance, this combination would let a user access files that are labeled INTERNAL Eng, INTERNAL Mkt, and INTERNAL Fin.

Account Label Range

When you assign a clearance and a minimum label to a user, you define the upper and lower boundaries of the account label range in which that user is permitted to operate. The following equation describes the account label range, using ≤ to indicate “dominated by or the same as”:

minimum label ≤ permitted label ≤ clearance

Thus, the user is permitted to operate at any label that is dominated by the clearance as long as that label dominates the minimum label. When a user's clearance or minimum label is not expressly set, the defaults that are defined in the label_encodings file take effect.

Users can be assigned a clearance and a minimum label that enable them to operate at more than one label, or at a single label. When a user's clearance and minimum label are equal, the user can operate at only one label.

Session Range

The session range is the set of labels that is available to a user during a Trusted Extensions session. The session range must be within the user's account label range and the label range set for the system. At login, if the user selects single-label session mode, the session range is limited to that label. If the user selects multilabel session mode, then the label that the user selects becomes the session clearance. The session clearance defines the upper boundary of the session range. The user's minimum label defines the lower bound. The user begins the session in a workspace at the minimum label. During the session, the user can switch to a workspace at any label within the session range.

What Labels Protect and Where Labels Appear

Labels appear on the desktop and on output that is executed on the desktop, such as printer output.

• Applications – Applications start processes. These processes run at the label of the workspace where the application is started. An application in a labeled zone, as a file, is labeled at the label of the zone.

• Devices – Data flowing through devices is controlled through device allocation and device label ranges. To use a device, users must be within the label range of the device, and be authorized to allocate the device.

• File system mount points – Every mount point has a label. The label is viewable by using the getlabel command.

• IPsec and IKE – IPsec security associations and IKE rules have labels.

• Network interfaces – IP addresses (hosts) have templates that describe their label range. Unlabeled hosts also have a default label.

• Printers and printing – Printers have label ranges. Labels are printed on body pages. Labels, handling information, and other security information is printed on the banner and trailer pages. To configure printing in Trusted Extensions, see Chapter 21, Managing Labeled Printing (Tasks) and Labels on Printed Output in Solaris Trusted Extensions Label Administration.

• Processes – Processes are labeled. Processes run at the label of the workspace where the process originates. The label of a process is visible by using the plabel command.

• Users – Users are assigned a default label and a label range. The label of the user's workspace indicates the label of the user's processes.

• Windows – Labels are visible at the top of desktop windows. The label of the desktop is also indicated by color. The color appears on the desktop switch and above window title bars.

  When a window is moved to a differently labeled workspace, the window maintains its original label.

• Zones – Every zone has a unique label. The files and directories that are owned by a zone are at the zone's label. For more information, see the getzonepath(1) man page.

Chapter 8 Trusted Extensions Administration Tools

This chapter describes the tools that are available in Solaris Trusted Extensions, the location of the tools, and the databases on which the tools operate.

• Administration Tools for Trusted Extensions

• Device Manager

• Solaris Management Console Tools

• Command Line Tools in Trusted Extensions

• Configuration Files in Trusted Extensions

• Remote Administration in Trusted Extensions

Administration Tools for Trusted Extensions

Administration on a system that is configured with Trusted Extensions uses many of the same tools that are available in the Solaris OS. Trusted Extensions offers security-enhanced tools as well. Administration tools are available only to roles in a role workspace.

Within a role workspace, you can access commands, applications, and scripts that are trusted. The following table summarizes these administrative tools.

txzonemgr Script

In the Solaris Express Community Edition, the txzonemgr script is used to configure labeled zones. This zenity(1) script displays a dialog box with the title Labeled Zone Manager. This GUI presents a dynamically-determined menu that displays only valid choices for the current configuration status of a labeled zone. For instance, if a zone is already labeled, the Label menu item is not displayed.

Device Manager

A device is either a physical peripheral that is connected to a computer or a software-simulated device called a pseudo-device. Because devices provide a means for the import and export of data to and from a system, devices must be controlled to properly protect the data. Trusted Extensions uses device allocation and device label ranges to control data flowing through devices.

Examples of devices that have label ranges are frame buffers, tape drives, diskette and CD-ROM drives, printers, and USB devices.

Users allocate devices through the Device Manager. The Device Manager mounts the device, runs a clean script to prepare the device, and performs the allocation. When finished, the user deallocates the device through the Device Manager, which runs another clean script, and unmounts and deallocates the device.

You can manage devices by using the Device Administration tool from the Device Manager. Regular users cannot access the Device Administration tool.

For more information about device protection in Trusted Extensions, see Chapter 23, Managing Devices for Trusted Extensions (Tasks).

Solaris Management Console Tools

The Solaris Management Console provides access to toolboxes of GUI-based administration tools. These tools enable you to edit items in various configuration databases. In Trusted Extensions, the Solaris Management Console is the administrative interface for users, roles, and the trusted network databases.

Trusted Extensions extends the Solaris Management Console:

• Trusted Extensions modifies the Solaris Management Console Users tool set. For an introduction to the tool set, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.

• Trusted Extensions adds the Security Templates tool and the Trusted Network Zones tool to the Computers and Networks tool set.

Solaris Management Console tools are collected into toolboxes according to scope and security policy. To administer Trusted Extensions, Trusted Extensions provides toolboxes whose Policy=TSOL. You can access tools according to scope, that is, according to naming service. The available scopes are local host and LDAP.

The Solaris Management Console is shown in the following figure. A Scope=Files Trusted Extensions toolbox is loaded, and the Users tool set is open.

Figure 8–1 Typical Trusted Extensions Toolbox in the Solaris Management Console

Trusted Extensions Tools in the Solaris Management Console

Trusted Extensions adds configurable security attributes to three tools:

• User Accounts tool – Is the administrative interface to change a user's label, change a user's view of labels, and to control account usage.

• Administrative Roles tool – Is the administrative interface to change a role's label range and screen-locking behavior when idle.

Trusted Extensions adds two tools to the Computers and Networks tool set:

• Security Templates tool – Is the administrative interface for managing the label aspects of hosts and networks. This tool modifies the tnrhtp and tnrhdb databases, enforces syntactic accuracy, and updates the kernel with the changes.

• Trusted Network Zones tool – Is the administrative interface for managing the label aspects of zones. This tool modifies the tnzonecfg database, enforces syntactic accuracy, and updates the kernel with the changes.

Figure 8–2 shows the Files toolbox with the Users tool set highlighted. The Trusted Extensions tools appear below the Computers and Networks tool set.

Figure 8–2 Computers and Networks Tool Set in the Solaris Management Console

Security Templates Tool

A security template describes a set of security attributes that can be assigned to a group of hosts. The Security Templates tool enables you to conveniently assign a specific combination of security attributes to a group of hosts. These attributes control how data is packaged, transmitted, and interpreted. Hosts that are assigned to a template have identical security settings.

The hosts are defined in the Computers tool. The security attributes of the hosts are assigned in the Security Templates tool. The Modify Template dialog box contains two tabs:

• General tab – Describes the template. Includes its name, host type, default label, domain of interpretation (DOI), accreditation range, and set of discrete sensitivity labels.

• Hosts Assigned to Template tab – Lists all the hosts on the network that you have assigned to this template.

Trusted networking and security templates are explained in more detail in Chapter 18, Trusted Networking (Overview).

Trusted Network Zones Tool

The Trusted Network Zones tool identifies the zones on your system. Initially, the global zone is listed. When you add zones and their labels, the zone names display in the pane. Zone creation usually occurs during system configuration. Label assignment, multilevel port configuration, and label policy is configured in this tool. For details, see Chapter 16, Managing Zones in Trusted Extensions (Tasks).

Client-Server Communication With the Solaris Management Console

Typically, a Solaris Management Console client administers systems remotely. On a network that uses LDAP as a naming service, a Solaris Management Console client connects to the Solaris Management Console server that runs on the LDAP server. The following figure shows this configuration.

Figure 8–3 Solaris Management Console Client Using an LDAP Server to Administer the Network

Figure 8–4 shows a network that is not configured with an LDAP server. The administrator configured each remote system with a Solaris Management Console server.

Figure 8–4 Solaris Management Console Client Administering Individual Remote Systems on a Network

Solaris Management Console Documentation

The main source of documentation for the Solaris Management Console is its online help. Context-sensitive help is tied to the currently selected feature and is displayed in the information pane. Expanded help topics are available from the Help menu or by clicking links in the context-sensitive help. Further information is provided in Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration. Also see Using the Solaris Management Tools With RBAC (Task Map) in System Administration Guide: Basic Administration.

Label Builder in Trusted Extensions

The label builder GUI enforces your choice of a valid label or clearance when a program requires you to assign a label. For example, a label builder appears during login (see Chapter 3, Logging In to Trusted Extensions (Tasks), in Solaris Trusted Extensions User’s Guide). The label builder also appears when you change the label of a workspace, or when you assign a label to a user, zone, or network interface in the Solaris Management Console. The following label builder appears when you assign a label range to a new device.

In the label builder, component names in the Classification column correspond to the CLASSIFICATIONS section in the label_encodings file. The component names in the Sensitivity column correspond to the WORDS section in the label_encodings file.

Command Line Tools in Trusted Extensions

Commands that are unique to Trusted Extensions are contained in the Solaris Trusted Extensions Reference Manual. The Solaris commands that Trusted Extensions modifies are contained in the Solaris Reference Manual. The man command finds all the commands.

The following table lists commands that are unique to Trusted Extensions. The commands are listed in man page format.

The following table lists Solaris commands that are modified or extended by Trusted Extensions. The commands are listed in man page format.

Configuration Files in Trusted Extensions

The following Solaris configuration files are modified or extended by Trusted Extensions. The files are introduced in man page format.

• ike.config(4) – Trusted Extensions adds the label_aware global parameter and three Phase 1 transform parameters, single_label and multi_label, and wire_label.

  ---

  Note –

  The IKE configuration file contains a keyword, label, that is used to make a Phase 1 IKE rule unique. The IKE keyword label is distinct from Trusted Extensions labels.

  ---

Remote Administration in Trusted Extensions

You can remotely administer a system that is configured with Trusted Extensions by using the ssh command, the dtappsession program, or the Solaris Management Console. If site security policy permits, you can configure a Trusted Extensions host to enable login from a non-Trusted Extensions host, although this configuration is less secure. For more information, see Chapter 14, Remote Administration in Trusted Extensions (Tasks).

Chapter 9 Getting Started as a Trusted Extensions Administrator (Tasks)

This chapter introduces you to administering a system that is configured with Solaris Trusted Extensions.

• Security Requirements When Administering Trusted Extensions

• Getting Started as a Trusted Extensions Administrator (Task Map)

Security Requirements When Administering Trusted Extensions

In Trusted Extensions, roles are the conventional way to administer the system. Typically, superuser is not used. Roles are created just as they are in the Solaris OS, and most tasks are performed by roles. In Trusted Extensions, the root user is not used to perform administrative tasks.

The following roles are typical of a Trusted Extensions site:

• root role – Created by the initial setup team

• Security Administrator role – Created during or after initial configuration by the initial setup team

• System Administrator role – Created by the Security Administrator role

As in the Solaris OS, you might also create a Primary Administrator role, an Operator role, and so on. With the exception of the root role, the roles that you create can be administered in a naming service.

As in the Solaris OS, only users who have been assigned a role can assume that role. In Solaris Trusted Extensions (GNOME), you can assume a role when your user name is displayed in the Trusted Stripe. The role choices appear when you click your user name.

Role Creation in Trusted Extensions

To administer Trusted Extensions, you create roles that divide system and security functions. The initial setup team created the Security Administrator role during configuration. For details, see Create the Security Administrator Role in Trusted Extensions.

The process of creating a role in Trusted Extensions is identical to the Solaris OS process. As described in Chapter 8, Trusted Extensions Administration Tools, the Solaris Management Console is the GUI for managing roles in Trusted Extensions.

• For an overview of role creation, see Chapter 10, Role-Based Access Control (Reference), in System Administration Guide: Security Services and Using RBAC (Task Map) in System Administration Guide: Security Services.

• To create a powerful role that is equivalent to superuser, see Creating the Primary Administrator Role in System Administration Guide: Basic Administration. At sites that use Trusted Extensions, the Primary Administrator role might violate security policy. These sites would turn root into a role, and create a Security Administrator role.

• To create the root role, see How to Make root User Into a Role in System Administration Guide: Security Services.

• To create roles by using the Solaris Management Console, see How to Create and Assign a Role by Using the GUI in System Administration Guide: Security Services.

Role Assumption in Trusted Extensions

Unlike the Solaris OS, Trusted Extensions provides an Assume Rolename Role menu item from the Trusted Path menu. After confirming the role password, the software activates a role workspace with the trusted path attribute. Role workspaces are administrative workspaces. Such workspaces are in the global zone.

Getting Started as a Trusted Extensions Administrator (Task Map)

Familiarize yourself with the following procedures before administering Trusted Extensions.

How to Enter the Global Zone in Trusted Extensions

By assuming a role, you enter the global zone in Trusted Extensions. Administration of the entire system is possible only from the global zone. Only superuser or a role can enter the global zone.

After assuming a role, the role can create a workspace at a user label to edit administration files in a labeled zone.

For troubleshooting purposes, you can also enter the global zone by starting a Failsafe session. For details, see How to Log In to a Failsafe Session in Trusted Extensions.

Before You Begin

You have created one or more roles, or you plan to enter the global zone as superuser. For pointers, see Role Creation in Trusted Extensions.

1. Use a trusted mechanism.

   In Solaris Trusted Extensions (GNOME), click your user name in the trusted stripe and choose a role.

   If you have been assigned a role, the role names are displayed in a list.

   For the location and significance of Trusted Extensions desktop features, see Chapter 5, Elements of Trusted Extensions (Reference), in Solaris Trusted Extensions User’s Guide.

2. At the prompt, type the role password.

   In Trusted GNOME, the current workspace changes to the role workspace.

   Click the role name on the trusted stripe, and from the menu, select a different role or user. This action changes the current workspace to the process of the new role or user.

How to Exit the Global Zone in Trusted Extensions

Before You Begin

You are in the global zone.

1. On the Trusted GNOME desktop, click your role name in the trusted stripe.

   You can also exit the role workspace from the role menu.

   When you click the role name, your user name and a list of roles that you can assume is displayed. When you select your user name, all subsequent windows that you create in that workspace are created by the selected name. The windows that you previously created on the current desktop continue to display at the name and label of the role.

How to Administer the Local System With the Solaris Management Console

The first time that you launch the Solaris Management Console on a system, a delay occurs while the tools are registered and various directories are created. This delay typically occurs during system configuration. For the procedure, see Initialize the Solaris Management Console Server in Trusted Extensions.

To administer a remote system, see Administering Trusted Extensions Remotely (Task Map).

Before You Begin

You must have assumed a role. For details, see How to Enter the Global Zone in Trusted Extensions.

1. Start the Solaris Management Console.

   In Solaris Trusted Extensions (GNOME), use the command line.

   $ /usr/sbin/smc &

2. Choose Console -> Open Toolbox.

3. From the list, select a Trusted Extensions toolbox of the appropriate scope.

   A Trusted Extensions toolbox has Policy=TSOL as part of its name. The Files scope updates local files on the current system. The LDAP scope updates LDAP directories on the Sun Java^TM System Directory Server. The toolbox names appear similar to the following:

   This Computer (this-host: Scope=Files, Policy=TSOL) This Computer (ldap-server: Scope=LDAP, Policy=TSOL)

4. Navigate to the desired Solaris Management Console tool.

   The password prompt is displayed.

   For tools that Trusted Extensions has modified, click System Configuration.

5. Type the password.

   Refer to the online help for additional information about Solaris Management Console tools. For an introduction to the tools that Trusted Extensions modifies, see Solaris Management Console Tools.

6. To close the GUI, choose Exit from the Console menu.

How to Edit Administrative Files in Trusted Extensions

Administrative files are edited with a trusted editor that incorporates auditing. This editor also prevents the user from executing shell commands and from saving to any file name other than the name of the original file.

1. Assume a role.

   For details, see How to Enter the Global Zone in Trusted Extensions.

2. Open a trusted editor.

   In Solaris Trusted Extensions (GNOME), do the following:

   • (Optional) To use gedit as the trusted editor, modify the EDITOR variable.

     For details, see How to Assign the Editor of Your Choice as the Trusted Editor.

   • Use the command line to bring up the trusted editor.

     # /usr/dt/bin/trusted_edit filename

     You must provide a filename argument.

3. To create a new file, type the full path name for the new file.

   When you save the file, the editor creates a temporary file.

4. To edit an existing file, type the full path name for the existing file.

   ---

   Note –

   If your editor provides a Save As option, do not use it. Use the editor's Save option to save the file.

   ---

5. To save the file to the specified path name, close the editor.

Chapter 10 Security Requirements on a Trusted Extensions System (Overview)

This chapter describes configurable security features on a system that is configured with Solaris Trusted Extensions.

• Configurable Solaris Security Features

• Security Requirements Enforcement

• Rules When Changing the Level of Security for Data

Configurable Solaris Security Features

Trusted Extensions uses the same security features that the Solaris OS provides, and adds some features. For example, the Solaris OS provides eeprom protection, password requirements and strong password algorithms, system protection by locking out a user, and protection from keyboard shutdown.

Trusted Extensions differs from the Solaris OS in the actual procedures that are used to modify these security defaults. In Trusted Extensions, you typically administer systems by assuming a role. Local settings are modified by using the trusted editor. Changes that affect the network of users, roles, and hosts are made in the Solaris Management Console.

Trusted Extensions Interfaces for Configuring Security Features

Procedures are provided in this book where Trusted Extensions requires a particular interface to modify security settings, and that interface is optional in the Solaris OS. Where Trusted Extensions requires the use of the trusted editor to edit local files, no separate procedures are provided in this book. For example, the procedure How to Prevent Account Locking for Users describes how to update a user's account by using the Solaris Management Console to prevent the account from being locked. However, the procedure for setting a system-wide password lock policy is not provided in this book. You follow the Solaris instructions, except that in Trusted Extensions, you use the trusted editor to modify the system file.

Extension of Solaris Security Mechanisms by Trusted Extensions

The following Solaris security mechanisms are extensible in Trusted Extensions as they are in the Solaris OS:

• Audit events and classes – Adding audit events and audit classes is described in Chapter 30, Managing Solaris Auditing (Tasks), in System Administration Guide: Security Services.

• Rights profiles – Adding rights profiles is described in Part III, Roles, Rights Profiles, and Privileges, in System Administration Guide: Security Services.

• Roles – Adding roles is described in Part III, Roles, Rights Profiles, and Privileges, in System Administration Guide: Security Services.

• Authorizations – For an example of adding a new authorization, see Customizing Device Authorizations in Trusted Extensions (Task Map).

As in the Solaris OS, privileges cannot be extended.

Trusted Extensions Security Features

Trusted Extensions provides the following unique security features:

• Labels – Subjects and objects are labeled. Processes are labeled. Zones and the network are labeled.

• Device Allocation Manager – By default, devices are protected by allocation requirements. The Device Allocation Manager GUI is the interface for administrators and for regular users.

• Change Password menu item – The Trusted Path menu enables you to change your user password, and the password of the role that you have assumed.

Security Requirements Enforcement

To ensure that the security of the system is not compromised, administrators need to protect passwords, files, and audit data. Users need to be trained to do their part. To be consistent with the requirements for an evaluated configuration, follow the guidelines in this section.

Users and Security Requirements

Each site's security administrator ensures that users are trained in security procedures. The security administrator needs to communicate the following rules to new employees and remind existing employees of these rules on a regular basis:

• Do not tell anyone your password.

  Anyone who knows your password can access the same information that you can without being identified and therefore without being accountable.

• Do not write your password down or include it in an email message.

• Choose passwords that are hard to guess.

• Do not send your password to anyone by email.

• Do not leave your computer unattended without locking the screen or logging off.

• Remember that administrators do not rely on email to send instructions to users. Do not ever follow emailed instructions from an administrator without first double-checking with the administrator.

  Be aware that sender information in email can be forged.

• Because you are responsible for the access permissions on files and directories that you create, make sure that the permissions on your files and directories are set appropriately. Do not allow unauthorized users to read a file, to change a file, to list the contents of a directory, or to add to a directory.

Your site might want to provide additional suggestions.

Email Usage

It is an unsafe practice to use email to instruct users to take an action.

Tell users not to trust email with instructions that purport to come from an administrator. Doing so prevents the possibility that spoofed email messages could be used to fool users into changing a password to a certain value or divulging the password, which could subsequently be used to log in and compromise the system.

Password Enforcement

The System Administrator role must specify a unique user name and user ID when creating a new account. When choosing the name and ID for a new account, the administrator you must ensure that both the user name and associated ID are not duplicated anywhere on the network and have not been previously used.

The Security Administrator role is responsible for specifying the original password for each account and for communicating the passwords to users of new accounts. You must consider the following information when administering passwords:

• Make sure that the accounts for users who are able to assume the Security Administrator role are configured so that the account cannot be locked. This practice ensures that at least one account can always log in and assume the Security Administrator role to reopen everyone's account if all other accounts are locked.

• Communicate the password to the user of a new account in such a way that the password cannot be eavesdropped by anyone else.

• Change an account's password if you have any suspicion that the password has been discovered by someone who should not know it.

• Never reuse user names or user IDs over the lifetime of the system.

  Ensuring that user names and user IDs are not reused prevents possible confusion about the following:

  • Which actions were performed by which user when audit records are analyzed

  • Which user owns which files when archived files are restored

Information Protection

You as an administrator are responsible for correctly setting up and maintaining discretionary access control (DAC) and mandatory access control (MAC) protections for security-critical files. Critical files include the following:

• shadow file – Contains encrypted passwords. See shadow(4).

• prof_attr database – Contains definitions of rights profiles. See prof_attr(4).

• exec_attr database – Contains commands that are part of rights profiles. See exec_attr(4).

• user_attr file – Contains the rights profiles, privileges, and authorizations that are assigned to local users. See user_attr(4).

• Audit trail – Contains the audit records that the auditing service has collected. See audit.log(4)

Because the protection mechanisms for LDAP entries are not subject to the access control policy enforced by the Trusted Extensions software, the default LDAP entries must not be extended, and their access rules must not be modified.

Password Protection

In local files, passwords are protected from viewing by DAC and from modifications by both DAC and MAC. Passwords for local accounts are maintained in the /etc/shadow file, which is readable only by superuser. For more information, see the shadow(4) man page.

Group Administration

The System Administrator role needs to verify on the local system and on the network that all groups have a unique group ID (GID).

When a local group is deleted from the system, the System Administrator role must ensure the following:

• All objects with the GID of the deleted group must be deleted or assigned to another group.

• All users who have the deleted group as their primary group must be reassigned to another primary group.

User Deletion Practices

When an account is deleted from the system, the System Administrator role and the Security Administrator role must take the following actions:

• Delete the account's home directories in every zone.

• Delete any processes or jobs that are owned by the deleted account:

  • Delete any objects that are owned by the account,or assign the ownership to another user.

  • Delete any at or batch jobs that are scheduled on behalf of the user. For details, see the at(1) and crontab(1) man pages.

• Never reuse the user (account) name or user ID.

Rules When Changing the Level of Security for Data

By default, regular users can perform cut-and-paste, copy-and-paste, and drag-and-drop operations on both files and selections. The source and target must be at the same label.

To change the label of files, or the label of information within files requires authorization. When users are authorized to change the security level of data, the Selection Manager application mediates the transfer. The /usr/share/gnome/sel_config file controls file relabeling actions, and the cutting and copying of information to a different label. The /usr/bin/tsoljdsselmgr application controls drag-and-drop operations between windows. As the following tables illustrate, the relabeling of a selection is more restrictive than the relabeling of a file.

The following table summarizes the rules for file relabeling. The rules cover cut-and-paste, copy-and-paste, and drag-and-drop operations.

Different rules apply to selections within a window or file. Drag-and-drop of selections always requires equality of labels and ownership. Drag-and-drop between windows is mediated by the Selection Manager application, not by the sel_config file.

The rules for changing the label of selections are summarized in the following table.

Trusted Extensions provides a selection confirmer to mediate label changes. This window appears when an authorized user attempts to change the label of a file or selection. The user has 120 seconds to confirm the operation. To change the security level of data without this window requires the solaris.label.win.noview authorization, in addition to the relabeling authorizations. The following illustration shows a selection, zonename, in the window.

By default, the selection confirmer displays whenever data is being transferred to a different label. If a selection requires several transfer decisions, the automatic reply mechanism provides a way to reply once to the several transfers. For more information, see the sel_config(4) man page and the following section.

sel_config File

The sel_config file is checked to determine the behavior of the selection confirmer when an operation would upgrade or downgrade a label.

The sel_config file defines the following:

• A list of selection types to which automatic replies are given

• Whether certain types of operations can be automatically confirmed

• Whether a selection confirmer dialog box is displayed

Chapter 11 Administering Security Requirements in Trusted Extensions (Tasks)

This chapter contains tasks that are commonly performed on a system that is configured with Solaris Trusted Extensions.

Common Tasks in Trusted Extensions (Task Map)

The following task map describes procedures that set up a working environment for administrators of Trusted Extensions.

How to Assign the Editor of Your Choice as the Trusted Editor

The trusted editor uses the value of the $EDITOR environment variable as its editor.

Before You Begin

You must be in a role in the global zone.

1. Determine the value of the $EDITOR variable.

   # echo $EDITOR

   The following are editor possibilities. The $EDITOR variable might also not be set.

   • /usr/bin/gedit – Is the editor that GNOME provides. Trusted GNOME is the trusted version of that desktop.

   • /usr/bin/vi – Is the visual editor.

2. Set the value of the $EDITOR variable.

   • To set the value permanently, modify the value in the shell initialization file for the role.

     For example, in the role's home directory, modify the .kshrc file for a Korn shell, and the .cshrc file for a C shell.

   • To set the value for the current shell, set the value in the terminal window.

     For example, in a Korn shell, use the following commands:

     # setenv EDITOR=pathname-of-editor # export $EDITOR

     In a C shell, use the following command:

     # setenv EDITOR=pathname-of-editor

     In a Bourne shell, use the following commands:

     # EDITOR=pathname-of-editor # export EDITOR

Example 11–1 Specifying the Editor for the Trusted Editor

The Security Administrator role wants to use vi when editing system files. A user who has assumed the role modifies the .kshrc initialization file in the role's home directory.

$ cd /home/secadmin
$ vi .kshrc

## Interactive shell
set -o vi
...
export EDITOR=vi

The next time that any user assumes the Security Administrator role, vi is the trusted editor.

How to Change the Password for root

The Security Administrator role is authorized to change any account's password at any time by using the Solaris Management Console. However, the Solaris Management Console cannot change the password of a system account. A system account is an account whose UID is below 100. root is a system account because its UID is 0.

1. Become superuser.

   If your site has made superuser into the root role, assume the root role.

2. Choose Change Password from the trusted path menu.

   

3. Change the password, and confirm the change.

Example 11–2 Changing the Password for a Role

Any user who can assume a role that is defined in LDAP can use the Trusted Path menu to change the password for the role. The password is then changed in LDAP for all users who attempt to assume the role.

As in the Solaris OS, the Primary Administrator role can change the password for a role by using the Solaris Management Console. In Trusted Extensions, the Security Administrator role can change another role's password by using the Solaris Management Console.

How to Regain Control of the Desktop's Current Focus

The “Secure Attention” key combination can be used to break a pointer grab or a keyboard grab by an untrusted application. The key combination can also be used to verify if a pointer or a keyboard has been grabbed by a trusted application. On a multiheaded system that has been spoofed to display more than one trusted stripe, this key combination warps the pointer to the authorized trusted stripe.

1. To regain control of a Sun keyboard, use the following key combination.

   Press the keys simultaneously to regain control of the current desktop focus. On the Sun keyboard, the diamond is the Meta key.

   <Meta> <Stop>

   If the grab, such as a pointer, is not trusted, the pointer moves to the stripe. A trusted pointer does not move to the trusted stripe.

2. If you are not using a Sun keyboard, use the following key combination.

   <Alt> <Break>

   Press the keys simultaneously to regain control of the current desktop focus on your laptop.

Example 11–3 Testing If the Password Prompt Can Be Trusted

On an x86 system that is using a Sun keyboard, the user has been prompted for a password. The cursor has been grabbed, and is in the password dialog box. To check that the prompt is trusted, the user presses the <Meta> <Stop> keys simultaneously. When the pointer remains in the dialog box, the user knows that the password prompt is trusted.

If the pointer had moved to the trusted stripe, the user would know that the password prompt could not be trusted, and contact the administrator.

Example 11–4 Forcing the Pointer to the Trusted Stripe

In this example, a user is not running any trusted processes but cannot see the mouse pointer. To bring the pointer to the center of the trusted stripe, the user presses the <Meta> <Stop> keys simultaneously.

How to Obtain the Hexadecimal Equivalent for a Label

This procedure provides an internal hexadecimal representation of a label. This representation is safe for storing in a public directory. For more information, see the atohexlabel(1M) man page.

Before You Begin

You must be in the Security Administrator role in the global zone. For details, see How to Enter the Global Zone in Trusted Extensions.

1. To obtain a hexadecimal value for a label, do one of the following.

   • To obtain the hexadecimal value for a sensitivity label, pass the label to the command.

     $ atohexlabel "CONFIDENTIAL : NEED TO KNOW" 0x0004-08-68

   • To obtain the hexadecimal value for a clearance, use the -c option.

     $ atohexlabel -c "CONFIDENTIAL NEED TO KNOW" 0x0004-08-68

     ---

     Note –

     Human readable sensitivity labels and clearance labels are formed according to rules in the label_encodings file. Each type of label uses rules from a separate section of this file. When a sensitivity label and a clearance label both express the same underlying level of sensitivity, the labels have identical hexadecimal forms. However, the labels can have different human readable forms. System interfaces that accept human readable labels as input expect one type of label. If the text strings for the label types differ, these text strings cannot be used interchangeably.

     In the default label_encodings file, the text equivalent of a clearance label does not include a colon (:).

     ---

Example 11–5 Using the atohexlabel Command

When you pass a valid label in hexadecimal format, the command returns the argument.

$ atohexlabel 0x0004-08-68
0x0004-08-68

When you pass an administrative label, the command returns the argument.

$ atohexlabel admin_high
ADMIN_HIGH
atohexlabel admin_low
ADMIN_LOW

Troubleshooting

The error message atohexlabel parsing error found in <string> at position 0 indicates that the <string> argument that you passed to atohexlabel was not a valid label or clearance. Check your typing, and check that the label exists in your installed label_encodings file.

How to Obtain a Readable Label From Its Hexadecimal Form

This procedure provides a way to repair labels that are stored in internal databases. For more information, see the hextoalabel(1M) man page.

Before You Begin

You must be in the Security Administrator role in the global zone.

1. To obtain the text equivalent for an internal representation of a label, do one of the following.

   • To obtain the text equivalent for a sensitivity label, pass the hexadecimal form of the label.

     $ hextoalabel 0x0004-08-68 CONFIDENTIAL : NEED TO KNOW

   • To obtain the text equivalent for a clearance, use the -c option.

     $ hextoalabel -c 0x0004-08-68 CONFIDENTIAL NEED TO KNOW

How to Change Security Defaults in System Files

In Trusted Extensions, the security administrator changes or accesses default security settings on a system.

Files in the /etc/security and /etc/default directories contain security settings. On a Solaris system, superuser can edit these files. For Solaris security information, see Chapter 3, Controlling Access to Systems (Tasks), in System Administration Guide: Security Services.

Relax system security defaults only if site security policy allows you to.

Before You Begin

You must be in the Security Administrator role in the global zone.

1. Use the trusted editor to edit the system file.

   For details, see How to Edit Administrative Files in Trusted Extensions.

   File	Task	For More Information
   /etc/default/login	Reduce the allowed number of password tries.	See the example under How to Monitor All Failed Login Attempts in System Administration Guide: Security Services. passwd(1) man page
   /etc/default/kbd	Disable keyboard shutdown.	How to Disable a System’s Abort Sequence in System Administration Guide: Security Services Note – On hosts that are used by administrators for debugging, the default setting for KEYBOARD_ABORT allows access to the kadb kernel debugger. For more information about the debugger, see the kadb(1M) man page.
   /etc/security/policy.conf	Require a more powerful algorithm for user passwords.  Remove a basic privilege from all users of this host.  Restrict users of this host to Basic Solaris User authorizations.	policy.conf(4) man page
   /etc/default/passwd	Require users to change passwords frequently.  Require users to create maximally different passwords.  Require a longer user password.  Require a password that cannot be found in your dictionary.	passwd(1) man page

Chapter 12 Users, Rights, and Roles in Trusted Extensions (Overview)

This chapter describes essential decisions that you must make before creating regular users, and provides additional background information for managing user accounts. The chapter assumes that the initial setup team has set up roles and a limited number of user accounts. These users can assume the roles that are used to configure and administer Solaris Trusted Extensions. For details, see Creating Roles and Users in Trusted Extensions.

• User Security Features in Trusted Extensions

• Administrator Responsibilities for Users

• Decisions to Make Before Creating Users in Trusted Extensions

• Default User Security Attributes in Trusted Extensions

• Configurable User Attributes in Trusted Extensions

• Security Attributes That Must Be Assigned to Users

User Security Features in Trusted Extensions

Trusted Extensions software adds the following security features to users, roles, or rights profiles:

• A user has a label range within which the user can use the system.

• A role has a label range within which the role can be used to perform administrative tasks.

• Commands in a Trusted Extensions rights profile have a label attribute. The command must be performed within a label range, or at a particular label.

• Trusted Extensions software adds privileges and authorizations to the set of privileges and authorizations that are defined by the Solaris OS.

Administrator Responsibilities for Users

The System Administrator role creates user accounts. The Security Administrator role sets up the security aspects of an account.

If you are using the Sun Java^TM System Directory Server for the LDAP naming service, check that the initial setup team configured the tsol_ldap.tbx toolbox. For the procedure, see Configuring the Solaris Management Console for LDAP (Task Map).

For details on setting up users and roles, see the following:

• How to Create the First Role (Primary Administrator) in System Administration Guide: Basic Administration

• Setting Up User Accounts (Task Map) in System Administration Guide: Basic Administration

• Part III, Roles, Rights Profiles, and Privileges, in System Administration Guide: Security Services

System Administrator Responsibilities for Users

In Trusted Extensions, the System Administrator role is responsible for determining who can access the system. The system administrator is responsible for the following tasks:

• Adding and deleting users

• Adding and deleting roles

• Modifying user and role configurations, other than security attributes

Security Administrator Responsibilities for Users

In Trusted Extensions, the Security Administrator role is responsible for all security attributes of a user or role. The security administrator is responsible for the following tasks:

• Assigning and modifying the security attributes of a user, role, or rights profile

• Creating and modifying rights profiles

• Assigning rights profiles to a user or role

• Assigning privileges to a user, role, or rights profile

• Assigning authorizations to a user, a role, or rights profile

• Removing privileges from a user, role, or rights profile

• Removing authorizations from a user, role, or rights profile

Typically, the Security Administrator role creates rights profiles. However, if a profile needs capabilities that the Security Administrator role cannot grant, then superuser or the Primary Administrator role can create the profile.

Before creating a rights profile, the security administrator needs to analyze whether any of the commands in the new profile need privilege or authorization to be successful. The man pages for individual commands list the privileges and authorizations that might be needed.

Decisions to Make Before Creating Users in Trusted Extensions

The following decisions affect what users are able to do in Trusted Extensions and how much effort is required. Some decisions are the same as the decisions that you would make when installing the Solaris OS. However, decisions that are specific to Trusted Extensions can affect site security and ease of use.

• Decide whether to change default user security attributes in the policy.conf file. User defaults in the label_encodings file were configured by the initial setup team. For a description of the defaults, see Default User Security Attributes in Trusted Extensions.

• Decide which startup files, if any, to copy or link from each user's minimum-label home directory to the user's higher-level home directories. For the procedure, see How to Configure Startup Files for Users in Trusted Extensions.

• Decide if users can access peripheral devices, such as the microphone, CD-ROM drive, and JAZ drive.

  If access is permitted to some users, decide if your site requires additional authorizations to satisfy site security. For the default list of device-related authorizations, see How to Assign Device Authorizations. For a finer-grained set of device authorizations, see Customizing Device Authorizations in Trusted Extensions (Task Map).

Default User Security Attributes in Trusted Extensions

Settings in the label_encodings and the policy.conf files together define default security attributes for user accounts. The values that you explicitly set for a user override these system values. Some values that are set in these files also apply to role accounts. For security attributes that you can explicitly set, see Configurable User Attributes in Trusted Extensions.

label_encodings File Defaults

The label_encodings file defines a user's minimum label, clearance, and default label view. For details about the file, see the label_encodings(4) man page. Your site's label_encodings file was installed by your initial setup team. Their decisions were based on Devising a Label Strategy, and examples from Solaris Trusted Extensions Label Administration.

Label values that the security administrator explicitly sets for individual users in the Solaris Management Console are derived from the label_encodings file. Explicitly set values override the values in the label_encodings file.

policy.conf File Defaults in Trusted Extensions

The Solaris /etc/security/policy.conf file contains the default security settings for the system. Trusted Extensions adds two keywords to this file. You can add these keyword=value pairs to the file if you want to change the system-wide value. These keywords are enforced by Trusted Extensions.

The authorizations and rights profiles that are defined in the policy.conf file are in addition to any authorizations and profiles that are assigned to individual accounts. For the other fields, the individual user's value overrides the system value.

Planning User Security in Trusted Extensions includes a table of every policy.conf keyword. See also the policy.conf(4) man page.

Configurable User Attributes in Trusted Extensions

The Solaris Management Console 2.1 is your tool for creating and modifying user accounts. For users who can log in at more than one label, you might also want to set up .copy_files and .link_files files in each user's minimum–label home directory.

The User Accounts tool in the Solaris Management Console works as it does in the Solaris OS, with two exceptions:

• Trusted Extensions adds attributes to user accounts.

• Home directory server access requires administrative attention in Trusted Extensions.

  • You create the home directory server entry the same as you do on a Solaris system.

  • Then, you and the user perform additional steps to mount the home directory at every user label.

As described in How to Add a User With the Solaris Management Console’s Users Tool in System Administration Guide: Basic Administration, a wizard enables you to create user accounts quickly. After using the wizard, you can modify the user's default Trusted Extensions attributes.

For more information about the .copy_files and .link_files files, see .copy_files and .link_files Files.

Security Attributes That Must Be Assigned to Users

The Security Administrator role must specify some security attributes for new users, as the following table shows. For information about the files that contain default values, see Default User Security Attributes in Trusted Extensions.

Security Attribute Assignment to Users in Trusted Extensions

The Security Administrator role assigns security attributes to users in the Solaris Management Console after the user accounts are created. If you have set up correct defaults, your next step is to assign security attributes only for users who need exceptions to the defaults.

When assigning security attributes to users, the security administrator considers the following information:

Assigning Passwords

The Security Administrator role assigns passwords to user accounts after the accounts have been created. After this initial assignment, users can change their passwords.

As in the Solaris OS, users can be forced to change their passwords at regular intervals. The password aging options limit how long any intruder who is able to guess or steal a password could potentially access the system. Also, establishing a minimum length of time to elapse before changing a password prevents a user with a new password from reverting immediately to the old password. For details, see the passwd(1) man page.

---

Note –

The passwords for users who can assume roles must not be subject to any password aging constraints.

---

Assigning Roles

A user is not required to have a role. A single user can be assigned more than one role if doing so is consistent with your site's security policy.

Assigning Authorizations

As in the Solaris OS, assigning authorizations directly to a user adds those authorizations to existing authorizations. In Trusted Extensions, you add the authorizations to a rights profile, then assign the profile to the user.

Assigning Rights Profiles

As in the Solaris OS, the order of profiles is important. The profile mechanism uses the first instance of the command in an account's profile set.

You can use the sorting order of profiles to your advantage. If you want a command to run with different security attributes from those attributes that are defined for the command in an existing profile, create a new profile with the preferred assignments for the command. Then, insert that new profile before the existing profile.

---

Note –

Do not assign rights profiles that include administrative commands to a regular user. The profile would not work because a regular user cannot enter the global zone.

---

Changing Privilege Default

The default privilege set can be too liberal for many sites. To restrict the privilege set for any regular user on a system, change the policy.conf file setting. To change the privilege set for individual users, use the Solaris Management Console. For an example, see How to Restrict a User's Set of Privileges.

Changing Label Defaults

Changing a user's label defaults creates an exception to the user defaults in the label_encodings file.

Changing Audit Defaults

As in the Solaris OS, assigning audit classes to a user creates exceptions to the audit classes that are assigned in the /etc/security/audit_control file on the system. For more information about auditing, see Chapter 24, Trusted Extensions Auditing (Overview).

.copy_files and .link_files Files

In Trusted Extensions, files are automatically copied from the skeleton directory only into the zone that contains the account's minimum label. To ensure that zones at higher labels can use startup files, either the user or the administrator must create the files .copy_files and .link_files.

The Trusted Extensions files .copy_files and .link_files help to automate the copying or linking of startup files into every label of an account's home directory. Whenever a user creates a workspace at a new label, the updatehome command reads the contents of .copy_files and .link_files at the account's minimum label. The command then copies or links every listed file into the higher-labeled workspace.

The .copy_files file is useful when a user wants a slightly different startup file at different labels. Copying is preferred, for example, when users use different mail aliases at different labels. The .link-files file is useful when a startup file should be identical at any label that it is invoked. Linking is preferred, for example, when one printer is used for all labeled print jobs. For example files, see How to Configure Startup Files for Users in Trusted Extensions.

The following lists some startup files that you might want users to be able to link to higher labels or to copy to higher labels:

Chapter 13 Managing Users, Rights, and Roles in Trusted Extensions (Tasks)

This chapter provides the Solaris Trusted Extensions procedures for configuring and managing users, user accounts, and rights profiles.

• Customizing the User Environment for Security (Task Map)

• Managing Users and Rights With the Solaris Management Console (Task Map)

• Handling Other Tasks in the Solaris Management Console (Task Map)

Customizing the User Environment for Security (Task Map)

The following task map describes common tasks that you can perform when customizing a system for all users, or when customizing an individual user's account.

How to Modify Default User Label Attributes

You can modify the default user label attributes during the configuration of the first system. The changes must be copied to every Trusted Extensions host.

Before You Begin

You must be in the Security Administrator role in the global zone. For details, see How to Enter the Global Zone in Trusted Extensions.

1. Review the default user attribute settings in the /etc/security/tsol/label_encodings file.

   For the defaults, see label_encodings File Defaults.

2. Modify the user attribute settings in the label_encodings file.

   Use the trusted editor. For details, see How to Edit Administrative Files in Trusted Extensions.

   The label_encodings file should be the same on all hosts.

3. Distribute a copy of the file to every Trusted Extensions host.

How to Modify policy.conf Defaults

Changing the policy.conf defaults in Trusted Extensions is similar to changing any security-relevant system file in the Solaris OS. In Trusted Extensions, you use a trusted editor to modify system files.

Before You Begin

You must be in the Security Administrator role in the global zone. For details, see How to Enter the Global Zone in Trusted Extensions.

1. Review the default settings in the /etc/security/policy.conf file.

   For Trusted Extensions keywords, see Table 12–1.

2. Modify the settings.

   Use the trusted editor to edit the system file. For details, see How to Edit Administrative Files in Trusted Extensions.

Example 13–1 Changing the System's Idle Settings

In this example, the security administrator wants idle systems to return to the login screen. The default locks an idle system. Therefore, the Security Administrator role adds the IDLECMD keyword=value pair to the /etc/security/policy.conf file as follows:

IDLECMD=LOGOUT

The administrator also wants systems to be idle a shorter amount of time before logout. Therefore, the Security Administrator role adds the IDLETIME keyword=value pair to the policy.conf file as follows:

IDLETIME=10

The system now logs out the user after the system is idle for 10 minutes.

Example 13–2 Modifying Every User's Basic Privilege Set

In this example, the security administrator of a Sun Ray^TM installation does not want regular users to view the processes of other Sun Ray users. Therefore, on every system that is configured with Trusted Extensions, the administrator removes proc_info from the basic set of privileges. The PRIV_DEFAULT setting in the /etc/policy.conf file is modified as follows:

PRIV_DEFAULT=basic,!proc_info

Example 13–3 Hiding Labels on a System

In this example, the security administrator changes the default setting in a system's policy.conf file to hide labels. Any user on this system would not view labels, unless the user was specifically configured to be able to view labels. This setting is reasonable on a single-label system, or on a system that is available to the general public.

# /etc/security/policy.conf
…
LABELVIEW=hidesl

To configure a user to override this setting, see How to Hide Labels From a User.

Example 13–4 Assigning Printing-Related Authorizations to All Users of a System

In this example, the security administrator enables a public kiosk computer to print without labels by typing the following in the computer's /etc/security/policy.conf file. At the next boot, print jobs by all users of this kiosk print without page labels.

AUTHS_GRANTED= solaris.print.unlabeled

Then, the administrator decides to save paper by removing banner and trailer pages. She first ensures that the Always Print Banners checkbox in the Print Manager is not selected. She then modifies the policy.conf entry to read the following and reboots. Now, all print jobs are unlabeled, and have no banner or trailer pages.

AUTHS_GRANTED= solaris.print.unlabeled,solaris.print.nobanner

How to Configure Startup Files for Users in Trusted Extensions

Users can put a .copy_files file and .link_files file into their home directory at the label that corresponds to their minimum sensitivity label. Users can also modify the existing .copy_files and .link_files files at the users' minimum label. This procedure is for the administrator role to automate the setup for a site.

Before You Begin

You must be in the System Administrator role in the global zone. For details, see How to Enter the Global Zone in Trusted Extensions.

1. Create two Trusted Extensions startup files.

   You are going to add .copy_files and .link_files to your list of startup files.

   # cd /etc/skel # touch .copy_files .link_files

2. Customize the .copy_files file.

   1. Start the trusted editor.

      For details, see How to Edit Administrative Files in Trusted Extensions.

   2. Type the full pathname to the .copy_files file.

      /etc/skel/.copy_files

   3. Type into .copy_files, one file per line, the files to be copied into the user's home directory at all labels.

      Use .copy_files and .link_files Files for ideas. For sample files, see Example 13–5.

3. Customize the .link_files file.

   1. Type the full pathname to the .link_files file in the trusted editor.

      /etc/skel/.link_files

   2. Type into .link_files, one file per line, the files to be linked into the user's home directory at all labels.

4. Customize the other startup files for your users.

   • For a discussion of what to include in startup files, see Customizing a User’s Work Environment in System Administration Guide: Basic Administration.

   • For details, see How to Customize User Initialization Files in System Administration Guide: Basic Administration.

   • For an example, see Example 13–5.

5. (Optional) Create a skelP subdirectory for users whose default shell is a profile shell.

   The P indicates the Profile shell.

6. Copy the customized startup files into the appropriate skeleton directory.

7. Use the appropriate skelX pathname when you create the user.

   The X indicates the letter that begins the shell's name, such as B for Bourne, K for Korn, C for a C shell, and P for Profile shell.

Example 13–5 Customizing Startup Files for Users

In this example, the security administrator configures files for every user's home directory. The files are in place before any user logs in. The files are at the user's minimum label. At this site, the users' default shell is the C shell.

The security administrator creates a .copy_files and a .link_files file in the trusted editor with the following contents:

## .copy_files for regular users
## Copy these files to my home directory in every zone
.mailrc
.mozilla
.soffice
:wq

## .link_files for regular users with C shells
## Link these files to my home directory in every zone
.cshrc
.login
.Xdefaults
.Xdefaults-hostname
:wq

## .link_files for regular users with Korn shells
# Link these files to my home directory in every zone
.ksh
.profile
.Xdefaults
.Xdefaults-hostname
:wq

In the shell initialization files, the administrator ensures that the users' print jobs go to a labeled printer.

## .cshrc file
setenv PRINTER conf-printer1
setenv LPDEST  conf-printer1

## .ksh file
export PRINTER conf-printer1
export LPDEST  conf-printer1

The administrator modifies the .Xdefaults-home-directory-server file to force the dtterm command to source the .profile file for a new terminal.

## Xdefaults-HDserver
Dtterm*LoginShell: true

The customized files are copied to the appropriate skeleton directory.

$ cp .copy_files .link_files .cshrc .login .profile \
.mailrc .Xdefaults .Xdefaults-home-directory-server \
/etc/skelC
$ cp .copy_files .link_files .ksh .profile \
.mailrc .Xdefaults .Xdefaults-home-directory-server \
/etc/skelK

Troubleshooting

If you create a .copy_files files at your lowest label, then log in to a higher zone to run the updatehome command and the command fails with an access error, try the following:

• Verify that from the higher-level zone you can view the lower-level directory.

  higher-level zone# ls /zone/lower-level-zone/home/username ACCESS ERROR: there are no files under that directory

• If you cannot view the directory, then restart the automount service in the higher-level zone:

  higher-level zone# svcadm restart autofs

Unless you are using NFS mounts for home directories, the automounter in the higher-level zone should be loopback mounting from /zone/lower-level-zone/export/home/username to /zone/lower-level-zone/home/username.

How to Lengthen the Timeout When Relabeling Information

In Trusted Extensions, the Selection Manager mediates transfers of information between labels. The Selection Manager appears for drag-and-drop operations, and for cut-and-paste operations. Some applications require that you set a suitable timeout so that the Selection Manager has time to intervene. A value of two minutes is sufficient.

Do not change the default timeout value on an unlabeled system. The operations fail with the longer timeout value.

Before You Begin

You must be in the System Administrator role in the global zone. For details, see How to Enter the Global Zone in Trusted Extensions.

1. For the StarOffice^TM application, do the following:

   1. Navigate to the file office-install-directory/VCL.xcu.

      where office-install-directory is the StarOffice installation directory, for example:

      office-top-dir/share/registry/data/org/staroffice

   2. Change the SelectionTimeout property value to 120.

      Use the trusted editor. For details, see How to Edit Administrative Files in Trusted Extensions.

      The default value is three seconds. A value of 120 sets the timeout to two minutes.

2. For users of applications that rely on the GNOME ToolKit (GTK) library, change the selection timeout property value to two minutes.

   ---

   Note –

   As an alternative, you could have each user change the selection timeout property value.

   ---

   Most Sun Java^TM Desktop System applications use the GTK library. Web browsers such as Mozilla, Firefox, and Thunderbird use the GTK library.

   By default, the selection timeout value is 300, or five seconds. A value of 7200 sets the timeout to two minutes.

   1. Create a GTK startup file.

      Name the file .gtkrc-mine. The .gtkrc-mine file belongs in the user's home directory at the minimum label.

   2. Add the selection timeout value to the file.

      ## $HOME/.gtkrc-mine file *gtk-selection-timeout: 7200

      As in the Solaris OS, the gnome-settings-daemon reads this file on startup.

3. (Optional) Add the .gtkrc-mine file to the list in each user's .link_files file.

   For details, see How to Configure Startup Files for Users in Trusted Extensions.

How to Log In to a Failsafe Session in Trusted Extensions

In Trusted Extensions, failsafe login is protected. If a regular user has customized shell initialization files and now cannot log in, you can use failsafe login to fix the user's files.

Before You Begin

You must know the root password.

1. As in the Solaris OS, choose Options –> Failsafe Session on the login screen.

2. At the prompt, have the user provide the user name and password.

3. At the prompt for the root password, provide the password for root.

   You can now debug the user's initialization files.

Managing Users and Rights With the Solaris Management Console (Task Map)

In Trusted Extensions, you must use the Solaris Management Console to administer users, authorizations, rights, and roles. To manage users and their security attributes, assume the Security Administrator role.

How to Modify a User's Label Range in the Solaris Management Console

You might want to extend a user's label range to give the user read access to an administrative application. For example, a user who can log in to the global zone could then run the Solaris Management Console. The user could view, but not not change the contents.

Alternatively, you might want to restrict the user's label range. For example, a guest user might be limited to one label.

Before You Begin

You must be in the Security Administrator role in the global zone.

1. Open a Trusted Extensions toolbox in the Solaris Management Console.

   Use a toolbox of the appropriate scope. For details, see Initialize the Solaris Management Console Server in Trusted Extensions.

2. Under System Configuration, navigate to User Accounts.

   A password prompt might be displayed.

3. Type the role password.

4. Select the individual user from User Accounts.

5. Click the Trusted Extensions Attributes tab.

   

   • To extend the user's label range, choose a higher clearance.

     You can also lower the minimum label.

   • To restrict the label range to one label, make the clearance equal to the minimum label.

6. To save the changes, click OK.

How to Create a Rights Profile for Convenient Authorizations

Where site security policy permits, you might want to create a rights profile that contains authorizations for users who can perform tasks that require authorization. To enable every user of a particular system to be authorized, see How to Modify policy.conf Defaults.

Before You Begin

You must be in the Security Administrator role in the global zone.

1. Open a Trusted Extensions toolbox in the Solaris Management Console.

   Use a toolbox of the appropriate scope. For details, see Initialize the Solaris Management Console Server in Trusted Extensions.

2. Under System Configuration, navigate to Rights.

   A password prompt might be displayed.

3. Type the role password.

4. To add a rights profile, click Action –> Add Right.

5. Create a rights profile that contains one or more of the following authorizations.

   For the step-by-step procedure, see How to Create or Change a Rights Profile in System Administration Guide: Security Services.

   In the following figure, the Authorizations Included window shows the authorizations that might be convenient for users.

   

   • Allocate Device – Authorizes a user to allocate a peripheral device, such as a microphone.

     By default, Solaris users can read and write to a CD-ROM. However, in Trusted Extensions, only users who can allocate a device can access the CD-ROM drive. To allocate the drive for use requires authorization. Therefore, to read and write to a CD-ROM in Trusted Extensions, a user needs the Allocate Device authorization.

   • Downgrade DragNDrop or CutPaste Info – Authorizes a user to select information from a higher-level file and place that information in a lower-level file.

   • Downgrade File Label – Authorizes a user to lower the security level of a file

   • DragNDrop or CutPaste without viewing contents – Authorizes a user to move information without viewing the information that is being moved.

   • Print Postscript – Authorizes a user to print PostScript^TM files.

   • Print without Banner - Authorizes a user to print hard copy without a banner page.

   • Print without Label – Authorizes a user to print hard copy that does not display labels.

   • Remote Login – Authorizes a user to remotely log in.

   • Shutdown the System – Authorizes a user to shut down the system and to shut down a zone.

   • Upgrade DragNDrop or CutPaste Info – Authorizes a user to select information from a lower-level file and place that information in a higher-level file.

   • Upgrade File Label – Authorizes a user to heighten the security level of a file.

6. Assign the rights profile to a user or a role.

   For assistance, see the online help. For the step-by-step procedure, see How to Change the RBAC Properties of a User in System Administration Guide: Security Services.

Example 13–6 Assigning a Printing-Related Authorization to a Role

In the following example, the Security Administrator allows a role to print jobs without labels on body pages.

In the Solaris Management Console, the security administrator navigates to Administrative Roles. She views the rights profiles that are included in a particular role, then ensures that the print-related authorizations are contained in one of the role's rights profiles.

How to Restrict a User's Set of Privileges

Site security might require that users be permitted fewer privileges than users are assigned by default. For example, at a site that uses Trusted Extensions on Sun Ray systems, you might want to prevent users from viewing other users' processes on the Sun Ray server.

Before You Begin

You must be in the Security Administrator role in the global zone.

1. Open a Trusted Extensions toolbox in the Solaris Management Console.

   Use a toolbox of the appropriate scope. For details, see Initialize the Solaris Management Console Server in Trusted Extensions.

2. Under System Configuration, navigate to User Accounts.

   A password prompt might be displayed.

3. Type the role password.

4. Double–click the icon for the user.

5. Remove one or more of the privileges in the basic set.

   1. Double-click the icon for the user.

   2. Click the Rights tab.

      

   3. Click the Edit button to the right of the basic set in the right_extended_attr field.

   4. Remove proc_session or file_link_any.

      By removing the proc_session privilege, you prevent the user from examining any processes outside the user's current session. By removing the file_link_any privilege, you prevent the user from making hard links to files that are not owned by the user.

      ---

      Caution –

      Do not remove the proc_fork or the proc_exec privilege. Without these privileges, the user would not be able to use the system.

      ---

      

6. To save the changes, click OK.

How to Prevent Account Locking for Users

Trusted Extensions extends the user security features in the Solaris Management Console to include account locking. Turn off account locking for users who can assume a role.

Before You Begin

You must be in the Security Administrator role in the global zone.

1. Start the Solaris Management Console.

   Use a toolbox of the appropriate scope. For details, see Initialize the Solaris Management Console Server in Trusted Extensions.

2. Under System Configuration, navigate to User Accounts.

   A password prompt might be displayed.

3. Type the role password.

4. Double–click the icon for the user.

5. Click the Trusted Extensions Attributes tab.

6. In the Account Usage section, choose No from the pull-down menu next to Lock account after maximum failed logins.

7. To save the changes, click OK.

How to Hide Labels From a User

Hiding labels is useful at a site where users can work at a single label only. An organization might not want regular users to see labels or to be aware of mandatory access controls. Ordinary users can then work whose desktop closely resembles the desktop on a Solaris system.

Before You Begin

You must be in the Security Administrator role in the global zone.

1. Open a Trusted Extensions toolbox in the Solaris Management Console.

   Use a toolbox of the appropriate scope. For details, see Initialize the Solaris Management Console Server in Trusted Extensions.

2. Under System Configuration, navigate to User Accounts.

   A password prompt might be displayed.

3. Type the role password.

4. Double–click the icon for the user.

5. Click the Trusted Extensions Attributes tab.

6. Choose Hide from the Label: selection list.

   This setting overrides the value of LABELVIEW in the system's policy.conf file. For details, see Default User Security Attributes in Trusted Extensions.

7. To save the changes, click OK.

How to Enable a User to Change the Security Level of Data

A regular user or a role can be authorized to change the security level, or labels, of files and directories. The user or role, in addition to having the authorization, must be configured to work at more than one label. And, the labeled zones must be configured to permit relabeling. For the procedure, see How to Enable Files to be Relabeled From a Labeled Zone.

Changing the security level of data is a privileged operation. This task is for trustworthy users only.

Before You Begin

You must be in the Security Administrator role in the global zone.

1. Follow the procedure How to Create a Rights Profile for Convenient Authorizations to create a rights profile.

   The following authorizations enable a user to relabel a file:

   • Downgrade File Label

   • Upgrade File Label

   The following authorizations enable a user to relabel information within a file:

   • Downgrade DragNDrop or CutPaste Info

   • DragNDrop or CutPaste Info Without Viewing

   • Upgrade DragNDrop or CutPaste Info

2. Use the Solaris Management Console to assign the profile to the appropriate users and roles.

   For assistance, use the online help. For a step-by-step procedure, see How to Change the RBAC Properties of a User in System Administration Guide: Security Services.

How to Delete a User Account From a Trusted Extensions System

When a user is removed from the system, you must ensure that the user's home directory and any objects that the user owns are also deleted. As an alternative to deleting objects that are owned by the user, you might change the ownership of these objects to a valid user.

You must also ensure that all batch jobs that are associated with the user are also deleted. No objects or processes belonging to a removed user can remain on the system.

Before You Begin

You must be in the System Administrator role.

1. Archive the user's home directory at every label.

2. Archive the user's mail files at every label.

3. In the Solaris Management Console, delete the user account.

   1. Open a Trusted Extensions toolbox in the Solaris Management Console.

      Use a toolbox of the appropriate scope. For details, see Initialize the Solaris Management Console Server in Trusted Extensions.

   2. Under System Configuration, navigate to User Accounts.

      A password prompt might be displayed.

   3. Type the role password.

   4. Select the user account to be removed, and click the Delete button.

      You are prompted to delete the user's home directory and mail files. When you accept the prompt, the user's home directory and mail files are deleted in the global zone only.

4. In every labeled zone, manually delete the user's directories and mail files.

   ---

   Note –

   You are responsible for finding and deleting the user's temporary files at all labels, such as files in /tmp directories.

   ---

Handling Other Tasks in the Solaris Management Console (Task Map)

Follow Solaris procedures to handle tasks in the Solaris Management Console. You must be superuser, or in a role in the global zone.

Chapter 14 Remote Administration in Trusted Extensions (Tasks)

This chapter describes how to use Trusted Extensions administrative tools to administer a remote system.

• Secure Remote Administration in Trusted Extensions

• Methods for Administering Remote Systems in Trusted Extensions

• Remote Login by a Role in Trusted Extensions

• Administering Trusted Extensions Remotely (Task Map)

Secure Remote Administration in Trusted Extensions

By default, Trusted Extensions does not allow remote administration. Remote administration would present a significant security risk if users on remote untrusted systems could administer systems that are configured with Trusted Extensions. Therefore, systems are initially installed without the option of being remotely administered.

Until the network is configured, all remote hosts are assigned the admin_low security template. Therefore, the CIPSO protocol is not used or accepted for any connections. While in this initial state, systems are protected from remote attacks by several mechanisms. Mechanisms include netservices settings, default login policy, and PAM policy.

• When the netservices Service Management Facility (SMF) profile is set to limited, no remote services except secure shell are enabled. However, the ssh service cannot be used for remote logins because of the login and PAM policies.

• The root account cannot be used for remote logins because the default policy for CONSOLE in the /etc/default/login file prevents remote logins by root.

• Two PAM settings also affect remote logins.

  The pam_roles module always rejects local logins from accounts of type role. By default, this module also rejects remote logins. However, the system can be configured to accept remote logins by specifying allow_remote in the system's pam.conf entry.

  Additionally, the pam_tsol_account module rejects remote logins into the global zone unless the CIPSO protocol is used. The intent of this policy is for remote administration to be performed by another Trusted Extensions system.

To enable remote login functionality, both systems must assign their peer to a CIPSO security template. If this approach is not practical, the network protocol policy can be relaxed by specifying the allow_unlabeled option in the pam.conf file. If either policy is relaxed, the default network template must be changed so that arbitrary machines cannot access the global zone. The admin_low template should be used sparingly, and the tnrhdb database should be modified so that the wildcard address 0.0.0.0 does not default to the ADMIN_LOW label. For details, see Administering Trusted Extensions Remotely (Task Map) and How to Limit the Hosts That Can Be Contacted on the Trusted Network.

Methods for Administering Remote Systems in Trusted Extensions

Typically, administrators use the rlogin and ssh commands to administer remote systems from the command line. The Solaris Management Console can also be used. Also, a virtual networking computer (vnc) can be used to remotely display a multilevel desktop.

The following methods of remote administration are possible in Trusted Extensions:

• The root user can log in to a remote host from a terminal. See How to Log In Remotely From the Command Line in Trusted Extensions. This method works as it does on a Solaris system. This method is insecure.

• A role can log in to a remote host from a terminal in the role workspace. See How to Log In Remotely From the Command Line in Trusted Extensions.

• Administrators can start a Solaris Management Console server that is running on a remote system. See How to Remotely Administer Systems by Using the Solaris Management Console From a Trusted Extensions System.

• A user can log in to a remote multilevel desktop by using a vnc client program to connect to the Xvnc server on a Trusted Extensions system. See How to Use Xvnc to Remotely Access a Trusted Extensions System.

Remote Login by a Role in Trusted Extensions

As in the Solaris OS, a setting in the /etc/default/login file on each host must be changed to allow remote logins. Additionally, the pam.conf file might need to be modified. In Trusted Extensions, the security administrator is responsible for the change. For the procedures, see Enable Remote Login by root User in Trusted Extensions and Enable Remote Login by a Role in Trusted Extensions.

On both Trusted Extensions and Solaris hosts, remote logins might or might not require authorization. Remote Login Management in Trusted Extensions describes the conditions and types of logins that require authorization. By default, roles have the Remote Login authorization.

Remote Role-Based Administration From Unlabeled Hosts

In Trusted Extensions, users assume roles through the Trusted Path menu. The roles then operate in trusted workspaces. By default, roles cannot be assumed outside of the trusted path. If site policy permits, the security administrator can change the default policy. Administrators of unlabeled hosts that are running Solaris Management Console 2.1 client software can then administer trusted hosts.

• To change the default policy, see Enable Remote Login by a Role in Trusted Extensions.

• To administer systems remotely, see How to Log In Remotely From the Command Line in Trusted Extensions.

This policy change only applies when the user on the remote unlabeled system has a user account on the Trusted Extensions host. The Trusted Extensions user must have the ability to assume an administrative role. The role can then use the Solaris Management Console to administer the remote system.

If remote administration from a non-Trusted Extensions host is enabled, the administrative environment is less protected than a Trusted Extensions administrative workspace. Be cautious when typing passwords and other secure data. As a precaution, shut down all untrusted applications before starting the Solaris Management Console.

Remote Login Management in Trusted Extensions

A remote login between two Trusted Extensions hosts is considered to be an extension of the current login session.

An authorization is not required when the rlogin command does not prompt for a password. If an /etc/hosts.equiv file or a .rhosts file in the user's home directory on the remote host lists either the username or the host from which the remote login is being attempted, no password is required. For more information, see the rhosts(4) and rlogin(1) man pages.

For all other remote logins, including logins with the ftp command, the Remote Login authorization is required.

To create a rights profile that includes the Remote Login authorization, see Managing Users and Rights With the Solaris Management Console (Task Map).

Administering Trusted Extensions Remotely (Task Map)

The following task map describes the tasks used to administer a remote Trusted Extensions system.

How to Log In Remotely From the Command Line in Trusted Extensions

The telnet command cannot be used for remote role assumption because this command cannot pass the primary and role identities to the pam_roles module.

Before You Begin

The user and the role must be identically defined on the local and the remote system.

The role must have the Remote Login authorization. By default, this authorization is in the Remote Administration, and the Maintenance and Repair rights profiles.

The security administrator has completed the procedure Enable Remote Login by a Role in Trusted Extensions on every system that can be remotely administered. If the system can be administered from an unlabeled system, the procedure Enable Remote Login From an Unlabeled System has also been completed.

1. From the workspace of a user who can assume a role, log in to the remote host.

   Use the rlogin command, the ssh command, or the ftp command.

   • If the rlogin -l or ssh command is used to log in, all commands that are in the role's rights profiles are available.

   • If the ftp command is used, see the ftp(1) man page for the commands that are available.

How to Remotely Administer Systems by Using the Solaris Management Console From a Trusted Extensions System

The Solaris Management Console provides a remote administration interface to manage users, rights, roles, and the network. You assume a role to use the Console. In this procedure, you run the Console on the local system and specify the remote system as the server.

Before You Begin

You have completed the following procedures:

• On both systems –Initialize the Solaris Management Console Server in Trusted Extensions

• On the remote system –Enable Remote Login by a Role in Trusted Extensions and Enable the Solaris Management Console to Accept Network Communications

• On the remote system that is the LDAP server –Configuring the Solaris Management Console for LDAP (Task Map)

1. On the local system, log in as the user who is defined identically on the remote system.

2. Assume the role that you plan to use to administer the system.

3. In the role, start the Solaris Management Console.

   For details, see Initialize the Solaris Management Console Server in Trusted Extensions.

   1. In the Server dialog box, type the name of the remote server.

      • If you are using LDAP as a naming service, type the name of the LDAP server.

        Then, choose one of the following scopes.

        • To administer the databases in the naming service, choose the Scope=LDAP toolbox.

          This Computer (ldap-server: Scope=LDAP, Policy=TSOL)

        • To administer the local files on the LDAP server, choose the Scope=Files toolbox.

          This Computer (ldap-server: Scope=Files, Policy=TSOL)

      • If you are not using LDAP as a naming service, type the name of the remote system that you want to administer.

        Then, choose the Scope=Files toolbox.

        This Computer (remote-system: Scope=Files, Policy=TSOL)

4. Select a tool under System Configuration.

   When you select a tool such as User, a dialog box displays the Solaris Management Console server name, your user name, your role name, and a place to type the role's password. Make sure that the entries are correct.

5. In the role that is defined identically on the local and the remote systems, log in to the Solaris Management Console server.

   Type the role's password and press Login as Role. You can now use the Solaris Management Console to manage the system.

How to Remotely Administer Systems by Using the Solaris Management Console From an Unlabeled System

In this procedure, you run the Solaris Management Console client and server on the remote system, and display the Console on the local system.

Before You Begin

The Trusted Extensions system must have assigned the label ADMIN_LOW to the local system.

A system that is not running the CIPSO protocol, such as a Trusted Solaris system, is an unlabeled system from the viewpoint of a Trusted Extensions system.

The Solaris Management Console server on the remote system must be configured to accept the remote connection. For the procedure, see Enable the Solaris Management Console to Accept Network Communications.

Both systems must have the same user who is assigned the same role that can use the Solaris Management Console. The user can have the normal user's label range, but the role must have the range from ADMIN_LOW to ADMIN_HIGH.

You must be in an administrative role in the global zone.

1. Enable the local X server to display the remote Solaris Management Console.

   # xhost + TX-SMC-Server # echo $DISPLAY :n.n

2. On the local system, become the user who can assume a role for the Solaris Management Console.

   # su - same-username-on-both-systems

3. As that user, log in to the remote server as the role.

   $ rlogin -l same-rolename-on-both-systems TX-SMC-Server

4. Make sure that the environment variables that the Solaris Management Console uses have the correct values.

   1. Set the value of the DISPLAY variable.

      $ DISPLAY=local:n.n $ export DISPLAY=local:n.n

   2. Set the value of the LOGNAME variable to the user name.

      $ LOGNAME=same-username-on-both-systems $ export LOGNAME=same-username-on-both-systems

   3. Set the value of the USER variable to the role name.

      $ USER=same-rolename-on-both-systems $ export USER=same-rolename-on-both-systems

5. In the role, start the Solaris Management Console from the command line.

   $ /usr/sbin/smc &

6. Select a tool under System Configuration.

   When you select a tool such as User, a dialog box displays the Solaris Management Console server name, your user name, your role name, and a place to type the role's password. Make sure that the entries are correct.

7. As the role, log in to the server.

   Type the role's password and press Login as Role. You can now use the Solaris Management Console to manage the system.

   ---

   Note –

   When you try to access network database information from a system that is not the LDAP server, the operation fails. The Console allows you to log in to the remote host and open the toolbox. However, when you try to access or change information, the following error message indicates that you have selected Scope=LDAP on a system that is not the LDAP server:

   Management server cannot perform the operation requested. ... Error extracting the value-from-tool. The keys received from the client were machine, domain, Scope. Problem with Scope.

   ---

How to Enable Specific Users to Log In Remotely to the Global Zone in Trusted Extensions

The user's default label range and the zone's default behavior are changed to enable remote login by a non-role. You might want to complete this procedure for a tester who is using a remote labeled system. For security reasons, the tester's system should be running a disjoint label from other users.

Before You Begin

You must have a very good reason why this user can log in to the global zone.

You must be in the Security Administrator role in the global zone.

1. To enable specific users to log in to the global zone, assign them an administrative label range.

   Use the Solaris Management Console to assign a clearance of ADMIN_HIGH and a minimum label of ADMIN_LOW to each user. For details, see How to Modify a User's Label Range in the Solaris Management Console.

   The user's labeled zones must also permit login.

2. To enable remote login from a labeled zone into the global zone, do the following.

   1. Add a multilevel port for remote login to the global zone.

      Use the Solaris Management Console. Port 513 over the TCP protocol enables remote login. For an example, see How to Create a Multilevel Port for a Zone.

   2. Read the tnzonecfg changes into the kernel.

      # tnctl -fz /etc/security/tsol/tnzonecfg

   3. Restart the remote login service.

      # svcadm restart svc:/network/login:rlogin

How to Use Xvnc to Remotely Access a Trusted Extensions System

Virtual Network Computing (vnc) technology connects a client to a remote server, then displays the desktop of the remote server in a window on the client. Xvnc is the UNIX version of vnc, which is based on a standard X server. In Trusted Extensions, a client on any platform can connect to an Xvnc that is running Trusted Extensions software, log in to the Xvnc server, then display and work on a multilevel desktop.

Before You Begin

You have installed and configured Trusted Extensions software on the system that is going to be used as the Xvnc server. You have created and booted the labeled zones. Your Xvnc server recognizes the vnc clients by hostname or IP address.

You are superuser in the global zone of the system that is going to be used as the Xvnc server.

1. Configure the Xvnc server.

   For more information, see the Xvnc(1) and vncconfig(1) man pages.

   ---

   Caution –

   If you are running the Solaris 10 10/08 or the Solaris 10 5/08 release, you must patch your system before configuring the server. For a SPARC system, install the latest version of patch 125719. For an x86 system, install the latest version of patch 125720.

   ---

   1. Create the Xservers configuration directory.

      # mkdir -p /etc/dt/config

   2. Copy the /usr/dt/config/Xservers file to the /etc/dt/config directory.

      # cp /usr/dt/config/Xservers /etc/dt/config/Xservers

   3. Edit the /etc/dt/config/Xservers file to start up the Xvnc program instead of Xserver or Xorg.

      In this example, the entry is configured to log in to the server without a password. To successfully log in the desktop, the local UID must be none instead of console.

      The entry is split for display purposes. The entry must be on one line.

      # :0 Local local_uid@console root /usr/X11/bin/Xserver :0 -nobanner :0 Local local_uid@none root /usr/X11/bin/Xvnc :0 -nobanner -AlwaysShared -SecurityTypes None -geometry 1024x768x24 -depth 24

      ---

      Note –

      A safer configuration is to require a password by using the -SecurityTypes VncAuth parameter. The Xvnc(1) man page describes password requirements.

      ---

   4. Reboot the server or start the Xvnc server.

      # reboot

      After reboot, verify that the Xvnc program is running.

      # ps -ef | grep Xvnc root 2145 932 0 Jan 18 ? 6:15 /usr/X11/bin/Xvnc :0 -nobanner -AlwaysShared -SecurityTypes None -geometry 1024

2. On every vnc client of the Trusted Extensions Xvnc server, install vnc client software.

   For the client system, you have a choice of software. This example uses the Sun vnc software.

   # cd SUNW-pkg-directory # pkgadd -d . SUNWvncviewer

3. In a terminal window on a vnc client, connect to the server.

   % /usr/bin/vncviewer Xvnc-server-hostname

4. In the window that displays, type your name and password.

   Continue with the login procedure. For a description of the remaining steps, see Logging In to Trusted Extensions in Solaris Trusted Extensions User’s Guide.

   If you logged in to the server as superuser, you can administer the server immediately. If you logged in to the server as a user, you must assume a role to administer the system.

Chapter 15 Trusted Extensions and LDAP (Overview)

This chapter describes the use of the Sun Java^TM System Directory Server (Directory Server) for a system that is configured with Solaris Trusted Extensions.

• Using a Naming Service in Trusted Extensions

• Using the LDAP Naming Service in Trusted Extensions

Using a Naming Service in Trusted Extensions

To achieve uniformity of user, host, and network attributes within a security domain with multiple Trusted Extensions systems, a naming service is used for distributing most configuration information. LDAP is an example of a naming service. The nsswitch.conf file determines which naming service is used. LDAP is the recommended naming service for Trusted Extensions.

The Directory Server can provide the LDAP naming service for Trusted Extensions and Solaris clients. The server must include Trusted Extensions network databases, and the Trusted Extensions clients must connect to the server over a multilevel port. The security administrator specifies the multilevel port when configuring Trusted Extensions.

Trusted Extensions adds two trusted network databases to the LDAP server: tnrhdb and tnrhtp. These databases are administered by using the Security Templates tool in the Solaris Management Console. A toolbox of Scope=LDAP, Policy=TSOL stores configuration changes on the Directory Server.

• For information about the use of the LDAP naming service in the Solaris OS, see System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP).

• Setting up the Directory Server for Trusted Extensions clients is described in Chapter 5, Configuring LDAP for Trusted Extensions (Tasks). Trusted Extensions systems can be clients of a Solaris LDAP server by using an LDAP proxy server that is configured with Trusted Extensions.

Systems that are configured with Trusted Extensions cannot be clients of NIS or NIS+ masters.

Non-Networked Trusted Extensions Systems

If a naming service is not used at a site, administrators must ensure that configuration information for users, hosts, and networks is identical on all hosts. A change that is made on one host must be made on all hosts.

On a non-networked Trusted Extensions system, configuration information is maintained in the /etc, /etc/security, and /etc/security/tsol directories. The Security Templates tool in the Solaris Management Console enables you to modify network database parameters. Users, roles, and rights are modified in the User Accounts, Administrative Roles, and Rights tools. A toolbox on This Computer with Scope=Files, Policy=TSOL stores configuration changes locally.

Trusted Extensions LDAP Databases

Trusted Extensions extends the Directory Server's schema to accommodate the tnrhdb and tnrhtp databases. Trusted Extensions defines two new attributes, ipTnetNumber and ipTnetTemplateName, and two new object classes, ipTnetTemplate and ipTnetHost.

The attribute definitions are as follows:

ipTnetNumber
   ( 1.3.6.1.1.1.1.34 NAME 'ipTnetNumber'
     DESC 'Trusted network host or subnet address'
     EQUALITY caseExactIA5Match
     SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
     SINGLE-VALUE )

ipTnetTemplateName
   ( 1.3.6.1.1.1.1.35 NAME 'ipTnetTemplateName'
     DESC 'Trusted network template name'
     EQUALITY caseExactIA5Match
     SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
     SINGLE-VALUE )

The object class definitions are as follows:

ipTnetTemplate
   ( 1.3.6.1.1.1.2.18 NAME 'ipTnetTemplate' SUP top STRUCTURAL
     DESC 'Object class for Trusted network host templates'
     MUST ( ipTnetTemplateName )
     MAY ( SolarisAttrKeyValue ) )

ipTnetHost
   ( 1.3.6.1.1.1.2.19 NAME 'ipTnetHost' SUP top AUXILIARY
     DESC 'Object class for Trusted network host/subnet address
           to template mapping'
     MUST ( ipTnetNumber $ ipTnetTemplateName ) )

The cipso template definition in LDAP is similar to the following:

ou=ipTnet,dc=example,dc=example1,dc=exampleco,dc=com
 objectClass=top
 objectClass=organizationalUnit
 ou=ipTnet

 ipTnetTemplateName=cipso,ou=ipTnet,dc=example,dc=example1,dc=exampleco,dc=com
 objectClass=top
 objectClass=ipTnetTemplate
 ipTnetTemplateName=cipso
 SolarisAttrKeyValue=host_type=cipso;doi=1;min_sl=ADMIN_LOW;max_sl=ADMIN_HIGH;

 ipTnetNumber=0.0.0.0,ou=ipTnet,dc=example,dc=example1,dc=exampleco,dc=com
 objectClass=top
 objectClass=ipTnetTemplate
 objectClass=ipTnetHost
 ipTnetNumber=0.0.0.0
 ipTnetTemplateName=internal

Using the LDAP Naming Service in Trusted Extensions

The LDAP naming service is managed in Trusted Extensions as it is managed in the Solaris OS. The following is a sample of useful commands, and contains references to more detailed information:

• For strategies to solve LDAP configuration problems, see Chapter 13, LDAP Troubleshooting (Reference), in System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP).

• To troubleshoot client-to-server LDAP connection problems that are affected by labels, see How to Debug a Client Connection to the LDAP Server.

• To troubleshoot other client-to-server LDAP connection problems, see Chapter 13, LDAP Troubleshooting (Reference), in System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP).

• To display LDAP entries from an LDAP client, type:

  $ ldaplist -l $ ldap_cachemgr -g

• To display LDAP entries from an LDAP server, type:

  $ ldap_cachemgr -g $ idsconfig -v

• To list the hosts that LDAP manages, type:

  $ ldaplist -l hosts Long listing $ ldaplist hosts One-line listing

• To list information in the Directory Information Tree (DIT) on LDAP, type:

  $ ldaplist -l services | more dn: cn=apocd+ipServiceProtocol=udp,ou=Services,dc=exampleco,dc=com objectClass: ipService objectClass: top cn: apocd ipServicePort: 38900 ipServiceProtocol: udp ... $ ldaplist services name dn=cn=name+ipServiceProtocol=udp,ou=Services,dc=exampleco,dc=com

• To display the status of the LDAP service on the client, type:

  # svcs -xv network/ldap/client svc:/network/ldap/client:default (LDAP client) State: online since date See: man -M /usr/share/man -s 1M ldap_cachemgr See: /var/svc/log/network-ldap-client:default.log Impact: None.

• To start and stop the LDAP client, type:

  # svcadm enable network/ldap/client

  # svcadm disable network/ldap/client

• To start and stop the LDAP server in version 5.2 of Sun Java System Directory Server software, type:

  # installation-directory/slap-LDAP-server-hostname/start-slapd # installation-directory/slap-LDAP-server-hostname/stop-slapd

• To start and stop the LDAP server in version 6 of Sun Java System Directory Server software, type:

  # dsadm start /export/home/ds/instances/your-instance # dsadm stop /export/home/ds/instances/your-instance

• To start and stop a proxy LDAP server in version 6 of Sun Java System Directory Server software, type:

  # dpadm start /export/home/ds/instances/your-instance # dpadm stop /export/home/ds/instances/your-instance

Chapter 16 Managing Zones in Trusted Extensions (Tasks)

This chapter describes how non-global zones work on a system that is configured with Solaris Trusted Extensions. Also included are procedures that are unique to zones in Trusted Extensions.

• Zones in Trusted Extensions

• Global Zone Processes and Labeled Zones

• Zone Administration Utilities in Trusted Extensions

• Managing Zones (Task Map)

Zones in Trusted Extensions

A properly configured Trusted Extensions system consists of a global zone, which is the operating system instance, and one or more labeled non-global zones. During configuration, Trusted Extensions attaches a unique label to each zone, which creates labeled zones. The labels come from the label_encodings file. The administrators can create a zone for each label, but are not required to. It is possible to have more labels than labeled zones on a system. It is not possible to have more labeled zones than labels.

On a Trusted Extensions system, the file systems of a zone are usually mounted as a loopback file system (lofs). All writable files and directories in a labeled zone are at the label of the zone. By default, a user can view files that are in a zone at a lower label than the user's current label. This configuration enables users to view their home directories at lower labels than the label of the current workspace. Although users can view files at a lower label, they cannot modify them. Users can only modify files from a process that has the same label as the file.

In Trusted Extensions, the global zone is an administrative zone. The labeled zones are for regular users. Users can work in a zone whose label is within the user's accreditation range.

Every zone has an associated IP address and security attributes. A zone can be configured with multilevel ports (MLPs). Also, a zone can be configured with a policy for Internet Control Message Protocol (ICMP) broadcasts, such as ping.

For information about sharing directories from a labeled zone and about mounting directories from labeled zones remotely, see Chapter 17, Managing and Mounting Files in Trusted Extensions (Tasks) and Mounting Labeled ZFS Datasets.

Zones in Trusted Extensions are built on the Solaris zones product. For details, see Part II, Zones, in System Administration Guide: Virtualization Using the Solaris Operating System. In particular, patching and package installation issues affect Trusted Extensions. For details, see Chapter 23, Packages on an OpenSolaris System With Zones Installed, in System Administration Guide: Virtualization Using the Solaris Operating System and Chapter 26, Troubleshooting Miscellaneous Solaris Zones Problems, in System Administration Guide: Virtualization Using the Solaris Operating System.

Zones and IP Addresses in Trusted Extensions

Your initial setup team assigned IP addresses to the global zone and the labeled zones. Three types of configurations are documented in Creating Labeled Zones:

• The system has one IP address for the global zone and all labeled zones.

  This configuration is useful on a system that uses DHCP software to obtain its IP address. If no users are expected to log in, an LDAP server might have this configuration.

• The system has one IP address for the global zone, and one IP address that is shared by all zones, including the global zone. Any zone can have a combination of a unique address and a shared address.

  This configuration is useful on a system that regular users are going to log in to. It can also be used for a printer or an NFS server. This configuration conserves IP addresses.

• The system has one IP address for the global zone, and each labeled zone has a unique IP address.

  This configuration is useful for providing access to separate physical networks of single-level systems. Typically, each zone would have an IP address on a different physical network from the other labeled zones. Because this configuration is implemented with a single IP instance, the global zone controls the physical interfaces and manages global resources, such as the route table.

With the introduction of exclusive IP instances for a non-global zone, a fourth type of configuration is available in the Solaris OS. In the Solaris Express Community Edition, a non-global zone can be assigned its own IP instance and manage its own physical interfaces. In this configuration, each zone operates as if it is a distinct system. For a description, see Zone Network Interfaces in System Administration Guide: Virtualization Using the Solaris Operating System.

However, in such a configuration, each labeled zone operates as if it is a distinct single-labeled system. The multilevel networking features of Trusted Extensions rely on features of a shared IP stack. Administration procedures in Trusted Extensions assume that networking is controlled entirely by the global zone. Therefore, if your initial setup team has installed labeled zones with exclusive IP instances, you must provide or refer to site-specific documentation.

Zones and Multilevel Ports

By default, a zone cannot send packets to and receive packets from any other zone. Multilevel ports (MLPs) enable particular services on a port to accept requests within a range of labels or from a set of labels. These privileged services can reply at the label of the request. For example, you might want to create a privileged web browser port that can listen at all labels, but whose replies are restricted by label. By default, labeled zones have no MLPs.

The range of labels or set of labels that constrains the packets that the MLP can accept is based on the zone's IP address. The IP address is assigned a remote host template in the tnrhdb database. The label range or set of labels in the remote host template constrains the packets that the MLP can accept.

• The constraints on MLPs for different IP address configurations are as follows:

• On a system where the global zone has an IP address and each labeled zone has a unique IP address, an MLP for a particular service can be added to every zone. For example, the system could be configured so that the ssh service, over TCP port 22, is an MLP in the global zone and in every labeled zone.

• In a typical configuration, the global zone is assigned one IP address and labeled zones share a second IP address with the global zone. When an MLP is added to a shared interface, the service packet is routed to the labeled zone where the MLP is defined. The packet is accepted only if the remote host template for the labeled zone includes the label of the packet. If the range is ADMIN_LOW to ADMIN_HIGH, then all packets are accepted. A narrower range would discard packets that are not within the range.

  At most, one zone can define a particular port to be an MLP on a shared interface. In the preceding scenario, where the ssh port is configured as a shared MLP in a non-global zone, no other zone can receive ssh connections on the shared address. However, the global zone could define the ssh port as a private MLP for receipt of connections on its zone-specific address.

• On a system where the global zone and the labeled zones share an IP address, an MLP for the ssh service could be added to one zone. If the MLP for ssh is added to the global zone, then no labeled zone can add an MLP for the ssh service. Similarly, if the MLP for the ssh service is added to a labeled zone, then the global zone cannot be configured with an ssh MLP.

For an example of adding MLPs to labeled zones, see Example 19–16.

Zones and ICMP in Trusted Extensions

Networks transmit broadcast messages and send ICMP packets to systems on the network. On a multilevel system, these transmissions could flood the system at every label. By default, the network policy for labeled zones requires that ICMP packets be received only at the matching label.

Global Zone Processes and Labeled Zones

In Trusted Extensions, MAC policy applies to all processes, including processes in the global zone. Processes in the global zone run at the label ADMIN_HIGH. When files from a global zone are shared, they are shared at the label ADMIN_LOW. Therefore, because MAC prevents a higher-labeled process from modifying a lower-level object, the global zone usually cannot write to an NFS-mounted system.

However, in a limited number of cases, actions in a labeled zone can require that a global zone process modify a file in that zone.

To enable a global zone process to mount a remote file system with read/write permissions, the mount must be under the zone path of the zone whose label corresponds to that of the remote file system. But it must not be mounted under that zone's root path.

• The mounting system must have a zone at the identical label as the remote file system.

• The system must mount the remote file system under the zone path of the identically labeled zone.

  The system must not mount the remote file system under the zone root path of the identically labeled zone

Consider a zone that is named public at the label PUBLIC. The zone path is /zone/public/. All directories under the zone path are at the label PUBLIC, as in:

/zone/public/dev
/zone/public/etc
/zone/public/home/username
/zone/public/root
/zone/public/usr

Of the directories under the zone path, only files under /zone/public/root are visible from the public zone. All other directories and files at the label PUBLIC are accessible only from the global zone. The path /zone/public/root is the zone root path.

From the perspective of the public zone administrator, the zone root path is visible as /. Similarly, the public zone administrator cannot access a user's home directory in the zone path, /zone/public/home/username directory. That directory is visible only from the global zone. The public zone mounts that directory in the zone root path as /home/username. From the perspective of the global zone, that mount is visible as /zone/public/root/home/username.

The public zone administrator can modify /home/username. A global zone process, when files in a user's home directory need to be modified, does not use that path. The global zone uses the user's home directory in the zone path, /zone/public/home/username.

• Files and directories that are under the zone path, /zone/zonename/, but not under the zone root path, /zone/zonename/root directory, can be modified by a global zone process that runs at the label ADMIN_HIGH.

• Files and directories that are under the zone root path, /zone/public/root, can be modified by the labeled zone administrator.

For example, when a user allocates a device in the public zone, a global zone process that runs at the label ADMIN_HIGH modifies the dev directory in the zone path, /zone/public/dev. Similarly, when a user saves a desktop configuration, the desktop configuration file is modified by a global zone process in the /zone/public/home/username. Finally, to share files from a labeled zone, the global zone administrator creates the configuration file, dfstab, in the zone path, /zone/public/etc/dfs/dfstab. A labeled zone administrator cannot access that file, and cannot share files from the labeled zone. To share a labeled directory, see How to Share Directories From a Labeled Zone.

Zone Administration Utilities in Trusted Extensions

Some zone administration tasks can be performed from the command line. However, the simplest way to administer zones is to use the GUIs that Trusted Extensions provides:

• The configuration of zone security attributes is performed by using the Trusted Network Zones tool in the Solaris Management Console. For a description of the tool, see Trusted Network Zones Tool. For examples of zone configuration and creation, see Chapter 4, Configuring Trusted Extensions (Tasks) and How to Create a Multilevel Port for a Zone.

• The shell script, /usr/sbin/txzonemgr, provides a menu-based wizard for creating, installing, initializing, and booting zones. txzonemgr uses the zenity command. For details, see the zenity(1) man page.

Managing Zones (Task Map)

The following task map describes zone management tasks that are specific to Trusted Extensions. The map also points to common procedures that are performed in Trusted Extensions just as they are performed on a Solaris system.

How to Display Ready or Running Zones

This procedure creates a shell script that displays the labels of the current zone and all zones that the current zone dominates.

Before You Begin

You must be in the System Administrator role in the global zone.

1. Use the trusted editor to create the getzonelabels script.

   For details, see How to Edit Administrative Files in Trusted Extensions.

   Provide the pathname to the script, such as /usr/local/scripts/getzonelabels.

2. Add the following content, and save the file:

   #!/bin/sh # echo "NAME\t\tSTATUS\t\tLABEL" echo "====\t\t======\t\t=====" myzone=`zonename` for i in `/usr/sbin/zoneadm list -p` ; do zone=`echo $i | cut -d ":" -f2` status=`echo $i | cut -d ":" -f3` path=`echo $i | cut -d ":" -f4` if [ $zone != global ]; then if [ $myzone = global ]; then path=$path/root/tmp else path=$path/export/home fi fi label=`/usr/bin/getlabel -s $path |cut -d ":" -f2-9` if [ `echo $zone|wc -m` -lt 8 ]; then echo "$zone\t\t$status\t$label" else echo "$zone\t$status\t$label" fi done

3. Test the script in the global zone.

   # getzonelabels NAME STATUS LABEL ==== ====== ===== global running ADMIN_HIGH needtoknow running CONFIDENTIAL : NEED TO KNOW restricted ready CONFIDENTIAL : RESTRICTED internal running CONFIDENTIAL : INTERNAL public running PUBLIC

   When run from the global zone, the script displays the labels of all ready or running zones. Here is the global zone output for the zones that were created from the default label_encodings file:

Example 16–1 Displaying the Labels of All Ready or Running Zones

In the following example, a user runs the getzonelabels script in the internal zone.

# getzonelabels
NAME            STATUS          LABEL
====            ======          =====
internal        running         CONFIDENTIAL : INTERNAL
public          running         PUBLIC

How to Display the Labels of Mounted Files

This procedure creates a shell script that displays the mounted file systems of the current zone. When run from the global zone, the script displays the labels of all mounted file systems in every zone.

Before You Begin

You must be in the System Administrator role in the global zone.

1. Use the trusted editor to create the getmounts script.

   For details, see How to Edit Administrative Files in Trusted Extensions.

   Provide the pathname to the script, such as /usr/local/scripts/getmounts.

2. Add the following content and save the file:

   #!/bin/sh # for i in `/usr/sbin/mount -p | cut -d " " -f3` ; do /usr/bin/getlabel $i done

3. Test the script in the global zone.

   # /usr/local/scripts/getmounts /: ADMIN_LOW /dev: ADMIN_LOW /kernel: ADMIN_LOW /lib: ADMIN_LOW /opt: ADMIN_LOW /platform: ADMIN_LOW /sbin: ADMIN_LOW /usr: ADMIN_LOW /var/tsol/doors: ADMIN_LOW /zone/needtoknow/export/home: CONFIDENTIAL : NEED TO KNOW /zone/internal/export/home: CONFIDENTIAL : INTERNAL USE ONLY /zone/restricted/export/home: CONFIDENTIAL : RESTRICTED /proc: ADMIN_LOW /system/contract: ADMIN_LOW /etc/svc/volatile: ADMIN_LOW /etc/mnttab: ADMIN_LOW /dev/fd: ADMIN_LOW /tmp: ADMIN_LOW /var/run: ADMIN_LOW /zone/public/export/home: PUBLIC /root: ADMIN_LOW

Example 16–2 Displaying the Labels of File Systems in the restricted Zone

When run from a labeled zone by a regular user, the getmounts script displays the labels of all the mounted file systems in that zone. On a system where zones are created for every label in the default label_encodings file, the following is the output from the restricted zone:

# /usr/local/scripts/getmounts
/:      CONFIDENTIAL : RESTRICTED
/dev:   CONFIDENTIAL : RESTRICTED
/kernel:        ADMIN_LOW
/lib:   ADMIN_LOW
/opt:   ADMIN_LOW
/platform:      ADMIN_LOW
/sbin:  ADMIN_LOW
/usr:   ADMIN_LOW
/var/tsol/doors:        ADMIN_LOW
/zone/needtoknow/export/home:   CONFIDENTIAL : NEED TO KNOW
/zone/internal/export/home:     CONFIDENTIAL : INTERNAL USE ONLY
/proc:  CONFIDENTIAL : RESTRICTED
/system/contract:       CONFIDENTIAL : RESTRICTED
/etc/svc/volatile:      CONFIDENTIAL : RESTRICTED
/etc/mnttab:    CONFIDENTIAL : RESTRICTED
/dev/fd:        CONFIDENTIAL : RESTRICTED
/tmp:   CONFIDENTIAL : RESTRICTED
/var/run:       CONFIDENTIAL : RESTRICTED
/zone/public/export/home:       PUBLIC
/home/gfaden:   CONFIDENTIAL : RESTRICTED

How to Loopback Mount a File That Is Usually Not Visible in a Labeled Zone

This procedure enables a user in a specified labeled zone to view files that are not exported from the global zone by default.

Before You Begin

You must be in the System Administrator role in the global zone.

1. Halt the zone whose configuration you want to change.

   # zoneadm -z zone-name halt

2. Loopback mount a file or directory.

   For example, enable ordinary users to view a file in the /etc directory.

   # zonecfg -z zone-name add filesystem set special=/etc/filename set directory=/etc/filename set type=lofs add options [ro,nodevices,nosetuid] end exit

   ---

   Note –

   Certain files are not used by the system, so that loopback mounting them has no effect. For example, the /etc/dfs/dfstab file in a labeled zone is not checked by Trusted Extensions software. For more information, see Sharing Files From a Labeled Zone.

   ---

3. Start the zone.

   # zoneadm -z zone-name boot

Example 16–3 Loopback Mounting the /etc/passwd file

In this example, the security administrator wants to enable testers and programmers to check that their local passwords are set. After the sandbox zone is halted, it is configured to loopback mount the passwd file. Then, the zone is restarted.

# zoneadm -z sandbox halt
# zonecfg -z sandbox
 add filesystem
    set special=/etc/passwd
    set directory=/etc/passwd
    set type=lofs
    add options [ro,nodevices,nosetuid]
 end
 exit
# zoneadm -z sandbox boot

How to Disable the Mounting of Lower-Level Files

By default, users can view lower-level files. Remove the net_mac_aware privilege to prevent the viewing of all lower-level files from a particular zone. For a description of the net_mac_aware privilege, see the privileges(5) man page.

Before You Begin

You must be in the System Administrator role in the global zone.

1. Halt the zone whose configuration you want to change.

   # zoneadm -z zone-name halt

2. Configure the zone to prevent the viewing of lower-level files.

   Remove the net_mac_aware privilege from the zone.

   # zonecfg -z zone-name set limitpriv=default,!net_mac_aware exit

3. Restart the zone.

   # zoneadm -z zone-name boot

Example 16–4 Preventing Users From Viewing Lower-Level Files

In this example, the security administrator wants to prevent users on one system from being confused. Therefore, users can only view files at the label at which the users are working. So, the security administrator prevents the viewing of all lower-level files. On this system, users cannot see publicly available files unless they are working at the PUBLIC label. Also, users can only NFS mount files at the label of the zones.

# zoneadm -z restricted halt
# zonecfg -z restricted
 set limitpriv=default,!net_mac_aware
 exit
# zoneadm -z restricted boot

# zoneadm -z needtoknow halt
# zonecfg -z needtoknow
 set limitpriv=default,!net_mac_aware
 exit
# zoneadm -z needtoknow boot

# zoneadm -z internal halt
# zonecfg -z internal
 set limitpriv=default,!net_mac_aware
 exit
# zoneadm -z internal boot

Because PUBLIC is the lowest label, the security administrator does not run the commands for the PUBLIC zone.

How to Share a ZFS Dataset From a Labeled Zone

In this procedure, you mount a ZFS dataset with read/write permissions in a labeled zone. Because all commands are executed in the global zone, the global zone administrator controls the addition of ZFS datasets to labeled zones.

At a minimum, the labeled zone must be in the ready state to share a dataset. The zone can be in the running state.

Before You Begin

To configure the zone with the dataset, you first halt the zone.

1. Create the ZFS dataset.

   # zfs create datasetdir/subdir

   The name of the dataset can include a directory, such as zone/data.

2. In the global zone, halt the labeled zone.

   # zoneadm -z labeled-zone-name halt

3. Set the mount point of the dataset.

   # zfs set mountpoint=legacy datasetdir/subdir

   Setting the ZFS mountpoint property sets the label of the mount point when the mount point corresponds to a labeled zone.

4. Add the dataset to the zone as a file system.

   # zonecfg -z labeled-zone-name # zonecfg:labeled-zone-name> add fs # zonecfg:labeled-zone-name:dataset> set dir=/subdir # zonecfg:labeled-zone-name:dataset> set special=datasetdir/subdir # zonecfg:labeled-zone-name:dataset> set type=zfs # zonecfg:labeled-zone-name:dataset> end # zonecfg:labeled-zone-name> exit

   By adding the dataset as a file system, the dataset is mounted at /data in the zone before the dfstab file is interpreted. This step ensures that the dataset is not mounted before the zone is booted. Specifically, the zone boots, the dataset is mounted, then the dfstab file is interpreted.

5. Share the dataset.

   Add an entry for the dataset file system to the /zone/labeled-zone-name/etc/dfs/dfstab file. This entry also uses the /subdir pathname.

   share -F nfs -d "dataset-comment" /subdir

6. Boot the labeled zone.

   # zoneadm -z labeled-zone-name boot

   When the zone is booted, the dataset is mounted automatically as a read/write mount point in the labeled-zone-name zone with the label of the labeled-zone-name zone.

Example 16–5 Sharing and Mounting a ZFS Dataset From Labeled Zones

In this example, the administrator adds a ZFS dataset to the needtoknow zone and shares the dataset. The dataset, zone/data, is currently assigned to the /mnt mount point. Users in the restricted zone can view the dataset.

First, the administrator halts the zone.

# zoneadm -z needtoknow halt

Because the dataset is currently assigned to a different mount point, the administrator removes the previous assignment, then sets the new mount point.

# zfs set zoned=off zone/data
# zfs set mountpoint=legacy zone/data

Next, in the zonecfg interactive interface, the administrator explicitly adds the dataset to the needtoknow zone.

# zonecfg -z needtoknow
# zonecfg:needtoknow> add fs
# zonecfg:needtoknow:dataset> set dir=/data
# zonecfg:needtoknow:dataset> set special=zone/data
# zonecfg:needtoknow:dataset> set type=zfs
# zonecfg:needtoknow:dataset> end
# zonecfg:needtoknow> exit

Next, the administrator modifies the /zone/needtoknow/etc/dfs/dfstab file to share the dataset, then boots the needtoknow zone.

## Global zone dfstab file for needtoknow zone
share  -F nfs  -d "App Data on ZFS"  /data

# zoneadm -z needtoknow boot

The dataset is now accessible.

Users in the the restricted zone, which dominates the needtoknow zone, can view the mounted dataset by changing to the /data directory. They use the full path to the mounted dataset from the perspective of the global zone. In this example, machine1 is the host name of the system that includes the labeled zone. The administrator assigned this host name to a non-shared IP address.

# cd /net/machine1/zone/needtoknow/root/data

Troubleshooting

If the attempt to reach the dataset from the higher label returns the error not found or No such file or directory, the administrator must restart the automounter service by running the svcadm restart autofs command.

How to Enable Files to be Relabeled From a Labeled Zone

This procedure is a prerequisite for a user to be able to relabel files.

Before You Begin

You must be in the Security Administrator role in the global zone.

1. Halt the zone whose configuration you want to change.

   # zoneadm -z zone-name halt

2. Configure the zone to enable relabeling.

   Add the appropriate privileges to the zone. The windows privileges enable users to use drag-and-drop and cut-and-paste operations.

   • To enable downgrades, add the file_downgrade_sl privilege to the zone.

     # zonecfg -z zone-name set limitpriv=default,win_dac_read,win_mac_read,win_dac_write, win_mac_write,win_selection,file_downgrade_sl exit

   • To enable upgrades, add the sys_trans_label and file_upgrade_sl privileges to the zone.

     # zonecfg -z zone-name set limitpriv=default,win_dac_read,win_mac_read,win_dac_write, win_mac_write,win_selection,sys_trans_label,file_upgrade_sl exit

   • To enable both upgrades and downgrades, add all three privileges to the zone.

     # zonecfg -z zone-name set limitpriv=default,win_dac_read,win_mac_read,win_dac_write, win_mac_write,win_selection,sys_trans_label,file_downgrade_sl, file_upgrade_sl exit

3. Restart the zone.

   # zoneadm -z zone-name boot

   For the user and process requirements that permit relabeling, see the setflabel(3TSOL) man page. To authorize a user to relabel files, see How to Enable a User to Change the Security Level of Data.

Example 16–6 Enabling Upgrades From the internal Zone

In this example, the security administrator wants to enable authorized users on a system to upgrade files. By enabling users to upgrade information, the administrator enables them to protect the information at a higher level of security. In the global zone, the administrator runs the following zone administration commands.

# zoneadm -z internal halt
# zonecfg -z internal
 set limitpriv=default,sys_trans_label,file_upgrade_sl
 exit
# zoneadm -z internal boot

Authorized users can now upgrade internal information to restricted from the internal zone.

Example 16–7 Enabling Downgrades From the restricted Zone

In this example, the security administrator wants to enable authorized users on a system to downgrade files. Because the administrator does not add windows privileges to the zone, authorized users cannot use the File Manager to relabel files. To relabel files, users use the setlabel command.

By enabling users to downgrade information, the administrator permits users at a lower level of security to access the files. In the global zone, the administrator runs the following zone administration commands.

# zoneadm -z restricted halt
# zonecfg -z restricted
 set limitpriv=default,file_downgrade_sl
 exit
# zoneadm -z restricted boot

Authorized users can now downgrade restricted information to internal or public from the restricted zone by using the setlabel command.

How to Configure a Multilevel Port for NFSv3 Over udp

This procedure is used to enable NFSv3 read-down mounts over udp. The Solaris Management Console is used to add the MLP.

Before You Begin

You must be in the Security Administrator role in the global zone.

1. Start the Solaris Management Console.

   For details, see How to Administer the Local System With the Solaris Management Console.

2. Choose the Files toolbox.

   The title of the toolbox includes Scope=Files, Policy=TSOL.

3. Configure the zone and the MLP.

   1. Navigate to the Trusted Network Zones tool.

   2. Double-click the global zone.

   3. Add a multilevel port for the UDP protocol:

      1. Click Add for the Multilevel Ports for Zone's IP Addresses.

      2. Type 2049 for the port number, and click OK.

   4. Click OK to save the settings.

4. Close the Solaris Management Console.

5. Update the kernel.

   # tnctl -fz /etc/security/tsol/tnzonecfg

How to Create a Multilevel Port for a Zone

This procedure is used when an application that runs in a labeled zone requires a multilevel port (MLP) to communicate with the zone. In this procedure, a web proxy communicates with the zone. The Solaris Management Console is used to add the MLP.

Before You Begin

You must be in the Security Administrator role in the global zone. The labeled zone must exist. For details, see Creating Labeled Zones.

1. Start the Solaris Management Console.

   For details, see How to Administer the Local System With the Solaris Management Console.

2. Choose the Files toolbox.

   The title of the toolbox includes Scope=Files, Policy=TSOL.

3. Add the proxy host and the webservices host to the list of computers.

   1. Under System Configuration, navigate to the Computers and Networks tool.

   2. In the Computers tool, click the Action menu and choose Add Computer.

   3. Add the host name and IP address for the proxy host.

   4. Save the changes.

   5. Add the host name and IP address for the webservice host.

   6. Save the changes.

4. Configure the zone and the MLP.

   1. Navigate to the Trusted Network Zones tool.

   2. Select the labeled zone.

   3. In the MLP Configuration for Local IP Addresses section, specify the appropriate port/protocol field.

   4. Save the changes.

5. For the zone, customize a template by completing the following steps:

   1. Navigate to the Security Templates tool.

      Click the Action menu and choose Add Template.

   2. Use the host name for the template name.

   3. Specify CIPSO for the Host Type.

   4. Use the label of the zone for the Minimum Label and for the Maximum Label.

   5. Assign the zone label to the Security Label Set.

   6. Select the Hosts Explicitly Assigned tab.

   7. In the Add an Entry section, add the IP address that is associated with the zone.

   8. Save the changes.

6. Close the Solaris Management Console.

7. Start the zones.

   # zoneadm -z zone-name boot

8. In the global zone, add routes for the new addresses.

   For example, if the zones have a shared IP address, do the following:

   # route add proxy labeled-zones-IP-address # route add webservice labeled-zones-IP-address

Chapter 17 Managing and Mounting Files in Trusted Extensions (Tasks)

This chapter describes how LOFS, NFS, and ZFS mounts work on a system that is configured with Trusted Extensions. This chapter also covers how to back up and restore files.

• Sharing and Mounting Files in Trusted Extensions

• NFS Mounts in Trusted Extensions

• Sharing Files From a Labeled Zone

• Access to NFS Mounted Directories in Trusted Extensions

• Trusted Extensions Software and NFS Protocol Versions

• Mounting Labeled ZFS Datasets

• Backing Up, Sharing, and Mounting Labeled Files (Task Map)

Sharing and Mounting Files in Trusted Extensions

Trusted Extensions software supports the same file systems and file system management commands as the Solaris OS. Trusted Extensions adds the ability for a non-global zone to share files. In addition, Trusted Extensions attaches a unique label to every non-global zone. All the files and directories that belong to that zone are mounted at the label of the zone. Any shared file systems that belong to other zones or to NFS servers are mounted at the label of the owner. Trusted Extensions prevents any mounts that would violate the mandatory access control (MAC) policies for labeling. For example, a zone's label must dominate all of its mounted file system labels, and only equally labeled file systems can be mounted with read/write permissions.

NFS Mounts in Trusted Extensions

NFS mounts in Trusted Extensions are similar to Solaris mounts. The differences occur in the use of zone root pathnames when mounting a labeled zone in Trusted Extensions, and in the enforcement of MAC policy.

NFS shares in Trusted Extensions are similar to Solaris shares in a global zone. However, the sharing of files from a labeled zone on a multilevel system is unique to Trusted Extensions:

• Shares and mounts in the global zone – Sharing and mounting files in the global zone of a Trusted Extensions system is almost identical to the procedure in the Solaris OS. For mounting files, the automounter, the vfstab file, and the mount command can be used. For sharing files, the dfstab file is used.

• Mounts in labeled zones – Mounting files in labeled zones in Trusted Extensions is almost identical to mounting files in non-global zones in the Solaris OS. For mounting files, the automounter, the vfstab file, and the mount command can be used. In Trusted Extensions, a unique automount_home_label configuration file exists for each labeled zone.

• Shares in labeled zones – Files in a labeled zone can be shared at the label of the zone by using a dfstab file that is at the label of the zone, but is visible to the global zone only. So, configuring a labeled zone to share files is performed by the global zone administrator in the global zone. This configuration file is not visible from its labeled zone. For more discussion, see Global Zone Processes and Labeled Zones.

Labels affect which files can be mounted. Files are shared and mounted at a particular label. For a Trusted Extensions client to write to a file that is NFS-mounted, the file must be mounted with read/write permissions and be at the same label as the client. If you are mounting a file between two Trusted Extensions hosts, the server and the client must have compatible remote host templates of type cipso. If you are mounting a file between a Trusted Extensions host and an unlabeled host, files that are at the single label that is specified for the unlabeled host in the tnrhdb file can be mounted. Files that are mounted with LOFS can be viewed, but cannot be modified. For details on NFS mounts, see Access to NFS Mounted Directories in Trusted Extensions.

Labels also affect which directories and files can be viewed. By default, lower-level objects are available in a user's environment. Therefore, in the default configuration, a regular user can view files that are in a zone at a lower level than the user's current level. For example, users can see their lower-level home directories from a higher label. For details, see Home Directory Creation in Trusted Extensions.

If site security forbids the viewing of lower-level objects, you can make lower-level directories invisible to the user. For details, see How to Disable the Mounting of Lower-Level Files.

The mount policy in Trusted Extensions has no MAC overrides. Mounted files that are visible at a lower label can never be modified by a higher-label process. This MAC policy is also in effect in the global zone. A global zone ADMIN_HIGH process cannot modify an NFS-mounted file at a lower label, such as a PUBLIC file or an ADMIN_LOW file. MAC policies enforce the default configuration and are invisible to regular users. Regular users cannot see objects unless they have MAC access to them.

Sharing Files From a Labeled Zone

In the Solaris OS, a non-global zone cannot share directories from its zone. However, in Trusted Extensions, a labeled zone can share directories. The specification of which directories in a labeled zone can be shared is performed in the global zone by using a directory that is outside the root path of the zone. For more discussion, see Global Zone Processes and Labeled Zones.

/zone/labeled-zone/directories

Also called the zone path. Is the path from the global zone to the labeled zone. Every directory under labeled-zone is labeled the same as the zone.

/zone/labeled-zone/root/directories

Also called the zone root path. Is the root path of a labeled zone from the perspective of the global zone. From the perspective of the labeled zone, this is the zone's root, the / directory. This path is not used by the global zone to administer the zone.

To share directories from a labeled zone, the global zone administrator creates and modifies the dfstab file in the /etc directory of the zone path:

/zone/labeled-zone/etc/dfs/dfstab

This /etc directory is not visible from the labeled zone. This directory is distinct from the /etc directory that is visible from the zone:

Global zone view: /zone/labeled-zone/root/etc
Labeled zone view of the same directory: /etc

A dfstab file in this path does not enable labeled directories to be shared.

When the status of the labeled zone is ready or running, the files that are listed in the /zone/labeled-zone/etc/dfs/dfstab file are shared at the label of the zone. For the procedure, see How to Share Directories From a Labeled Zone.

Access to NFS Mounted Directories in Trusted Extensions

By default, NFS-mounted file systems are visible at the label of the exported file system. If the file system is exported with read/write permissions, users at that label can write to the files. NFS mounts that are at a lower label than the user's current session are visible to the user, but cannot be written to. Even if a file system is shared with read/write permissions, the mounting system can write to it only at the label of the mount.

To make lower-level directories that are NFS-mounted visible to users in a higher-level zone, the administrator of the global zone on the NFS server must export the parent directory. The parent directory is exported at its label. On the client side, each zone must have the net_mac_aware privilege. By default, labeled zones include the net_mac_aware privilege in their limitpriv set.

• Server configuration – On the NFS server, you export the parent directory in a dfstab file. If the parent directory is in a labeled zone, the dfstab file must be modified in the labeled zone of the parent directory. The dfstab file for a labeled zone is visible only from the global zone. For the procedure, see How to Share Directories From a Labeled Zone.

• Client configuration – The net_mac_aware privilege must be specified in the zone configuration file that is used during initial zone configuration. So, a user who is permitted to view all lower-level home directories must have the net_mac_aware privilege in every zone, except the lowest zone. For an example, see How to NFS Mount Files in a Labeled Zone.

Example 17–1 Providing Access to Lower-Level Home Directories

On the home directory server, the administrator creates and modifies the /zone/labeled-zone/etc/dfs/dfstab file in every labeled zone. The dfstab file exports the /export/home directory with read/write permissions. Thus, when the directory is mounted at the same label, the home directory is writable. To export the /export/home directory of PUBLIC, the administrator creates a workspace at the PUBLIC label on the home directory server, and from the global zone, modifies the /zone/public/etc/dfs/dfstab file.

On the client, the administrator of the global zone checks that every labeled zone, except the lowest label, has the net_mac_aware privilege. This privilege permits the mount. This privilege can be specified by using the zonecfg command during zone configuration. The lower-level home directory can only be viewed. MAC protects the files in the directory from modification.

Home Directory Creation in Trusted Extensions

Home directories are a special case in Trusted Extensions. You need to make sure that the home directories are created in every zone that a user can use. Also, the home directory mount points must be created in the zones on the user's system. For NFS-mounted home directories to work correctly, the conventional location for directories, /export/home, must be used. In Trusted Extensions, the automounter has been modified to handle home directories in every zone, that is, at every label. For details, see Changes to the Automounter in Trusted Extensions.

Home directories are created when users are created. In Trusted Extensions, the Solaris Management Console (Console) is used to create users, so the Console creates the home directories. However, the Console creates the home directories in the global zone of the home directory server. On that server, the directories are mounted by LOFS. Home directories are automatically created by the automounter if they are specified as LOFS mounts.

When you delete a user by using the Console, only the user's home directory in the global zone is deleted. The user's home directories in the labeled zones are not deleted. You are responsible for archiving and deleting the home directories in the labeled zones. For the procedure, see How to Delete a User Account From a Trusted Extensions System.

However, the automounter cannot automatically create home directories on remote NFS servers. Either the user must first log in to the NFS server or administrative intervention is required. To create home directories for users, see Enable Users to Access Their Home Directories in Trusted Extensions.

Changes to the Automounter in Trusted Extensions

In Trusted Extensions, each label requires a separate home directory mount. The automount command has been modified to handle these labeled automounts. For each zone, the automounter, autofs, mounts an auto_home_zone-name file. For example, the following is the entry for the global zone in the auto_home_global file:

+auto_home_global
*       -fstype=lofs    :/export/home/&

When a zone that permits lower-level zones to be mounted is booted, the following occurs. The home directories of lower-level zones are mounted read only under /zone/<zone-name>/export/home. The auto_home_<zone-name> map specifies the /zone path as the source directory for an lofs remount onto /zone/<zone-name>/home/<username>.

For example, the following is an auto_home_public entry in an auto_home_zone-at-higher-label map that is generated from a higher-level zone:

+auto_home_public
*       -fstype=lofs    :/zone/public/export/home/&

The following is the corresponding entry in the public zone:

auto_home_public
*       -fstype=lofs    :/export/home/&

When a home directory is referenced and the name does not match any entries in the auto_home_<zone-name> map, the map tries to match this loopback mount specification. The software creates the home directory when the following two conditions are met:

1. The map finds the match of the loopback mount specification

2. The home directory name matches a valid user whose home directory does not yet exist in zone-name

For details on changes to the automounter, see the automount(1M) man page.

Trusted Extensions Software and NFS Protocol Versions

In the Solaris Express Community Edition, Trusted Extensions software recognizes labels on NFS Version 3 (NFSv3) and NFSv4. You can use one of the following sets of mount options:

vers=4 proto=tcp
vers=3 proto=tcp
vers=3 proto=udp

Trusted Extensions has no restrictions on mounts over the tcp protocol. In NFSv3 and NFSv4, the tcp protocol can be used for same-label mounts and for read-down mounts. Read-down mounts require a multilevel port (MLP).

For NFSv3, Trusted Extensions behaves like the Solaris OS. The udp protocol is the default for NFSv3, but udp is used only for the initial mount operation. For subsequent NFS operations, the system uses tcp. Therefore, read-down mounts work for NFSv3 in the default configuration.

In the rare case that you have restricted NFSv3 mounts to use the udp protocol for initial and subsequent NFS operations, you must create an MLP for NFS operations that use the udp protocol. For the procedure, see How to Configure a Multilevel Port for NFSv3 Over udp.

A host that is configured with Trusted Extensions can also share its own file systems with unlabeled hosts. A file or directory that is exported to an unlabeled host is writable if its label equals the label that is associated with the remote host in its trusted networking database entries. A file or directory that is exported to an unlabeled host is readable only if its label is dominated by the label that is associated with the remote host.

Communications with systems that are running a release of Trusted Solaris software is possible only at a single label. The Trusted Extensions system and the Trusted Solaris system must assign to the other system a template with the unlabeled host type. The unlabeled host types must specify the same single label. As an unlabeled NFS client of a Trusted Solaris server, the label of the client cannot be ADMIN_LOW.

The NFS protocol that is used is independent of the local file system's type. Rather, the protocol depends on the type of the sharing computer's operating system. The file system type that is specified to the mount command or in the vfstab file for remote file systems is always NFS.

Mounting Labeled ZFS Datasets

You can apply a label to a ZFS dataset or mount a ZFS dataset with no label to a zone. The initially unlabeled ZFS dataset acquires the label of the mounting zone.

ZFS provides a security label attribute, mlslabel, that contains the label of the data in the dataset. The mlslabel property is inheritable. If the property is undefined, it defaults to the string none, which indicates no label.

When you mount a ZFS dataset in a labeled zone, the following occurs:

• If the dataset is not labeled, the value of the mlslabel property is changed to the label of the mounting zone.

  For the global zone, the mlslabel property is not set automatically. If you explicitly label the dataset admin_low, the dataset must be mounted read-only.

• If the dataset is labeled, the kernel verifies that the dataset label matches the label of the mounting zone. If the labels do not match, the mount fails.

  If read-down mounts are allowed in the zone, a lower-level dataset mounts read-only.

To set the mlslabel property from the command line, type something similar to the following:

# zfs set mlslabel=public export/publicinfo

The file_upgrade_sl privilege is required to set an initial label or to change a non-default label to a higher-level label. The file_downgrade_sl privilege is required to remove a label, that is, to set the label to none. This privilege is also required to change a non-default label to a lower-level label. When a ZFS dataset has an explicit label, the dataset cannot be mounted on a Solaris system that is not configured with Trusted Extensions.

Backing Up, Sharing, and Mounting Labeled Files (Task Map)

The following task map describes common tasks that are used to back up and restore data from labeled file systems, and to share and mount directories and files that are labeled.

How to Back Up Files in Trusted Extensions

1. Assume the Operator role.

   This role includes the Media Backup rights profile.

2. Use one of the following backup methods:

   • /usr/lib/fs/ufs/ufsdump for major backups

   • /usr/sbin/tar cT for small backups

   • A script calling either of these commands

     For example, the Budtool backup application calls the ufsdump command. See the ufsdump(1M) man page. For details on the T option to the tar command, see the tar(1) man page.

How to Restore Files in Trusted Extensions

1. Assume the System Administrator role.

   This role includes the Media Restore rights profile.

2. Use one of the following methods:

   • /usr/lib/fs/ufs/ufsrestore for major restores

   • /usr/sbin/tar xT for small restores

   • A script calling either of these commands

   For details on the T option to the tar command, see the tar(1) man page.

   ---

   Caution –

   Only these commands preserve labels.

   ---

How to Share Directories From a Labeled Zone

As in the Solaris OS, the Mounts and Shares tool in the Solaris Management Console is used to share and mount files from the global zone. The tool cannot be used to mount or share directories that originate in labeled zones. Create a dfstab file at the label of the zone, and then restart the zone to share the labeled directories.

Do not use proprietary names for shared file systems. The names of shared file systems are visible to every user.

Before You Begin

You must be superuser, or in the System Administrator role in the global zone on the file server.

1. Create a workspace at the label of the directory that is going to be shared.

   For details, see How to Add a Workspace at a Particular Label in Solaris Trusted Extensions User’s Guide.

2. Create a dfstab file in at the label of that zone.

   For each zone that will share a directory, repeat the following steps:

   1. Create the /etc/dfs directory in the zone.

      # mkdir -p /zone/zone-name/etc/dfs

   2. Open the trusted editor.

      For details, see How to Edit Administrative Files in Trusted Extensions.

   3. Type the full pathname of the dfstab file into the editor.

      # /zone/zone-name/etc/dfs/dfstab

   4. Add an entry to share a directory from that zone.

      The entry describes the directory from the perspective of the zone root path. For example, the following entry shares an application's files at the label of the containing zone:

      share -F nfs -o ro /viewdir/viewfiles

3. For each zone, share the directories by starting the zone.

   In the global zone, run one of the following commands for each zone. Each zone can share its directories in any of these ways. The actual sharing occurs when each zone is brought into the ready or running state.

   • If the zone is not in the running state and you do not want users to log in to the server at the label of the zone, set the zone state to ready.

     # zoneadm -z zone-name ready

   • If the zone is not in the running state and users are allowed to log in to the server at the label of the zone, boot the zone.

     # zoneadm -z zone-name boot

   • If the zone is already running, reboot the zone.

     # zoneadm -z zone-name reboot

4. Display the directories that are shared from your system.

   # showmount -e

5. To enable the client to mount the exported files, see How to NFS Mount Files in a Labeled Zone.

Example 17–2 Sharing the /export/share Directory at the PUBLIC Label

For applications that run at the label PUBLIC, the system administrator enables users to read the documentation in the /export/share directory of the public zone. The zone named public runs at the label PUBLIC.

First, the administrator creates a public workspace and edits the dfstab file.

# mkdir -p /zone/public/etc/dfs
# /usr/dt/bin/trusted_edit /zone/public/etc/dfs/dfstab

In the file, the administrator adds the following entry:

## Sharing PUBLIC user manuals
share -F nfs -o ro /export/appdocs

The administrator leaves the public workspace and returns to the Trusted Path workspace. Because users are not allowed to log in to this system, the administrator shares the files by putting the zone in the ready state:

# zoneadm -z public ready

Users can access the shared directories once the directories are mounted on the users' systems.

How to NFS Mount Files in a Labeled Zone

In Trusted Extensions, a labeled zone manages the mounting of files in its zone.

Files from unlabeled and labeled hosts can be mounted on a Trusted Extensions labeled host.

• To mount the files read/write from a single-label host, the assigned label of the remote host must be identical to the zone in which the file is being mounted.

• Files that are mounted by a higher-level zone are read-only.

• In Trusted Extensions, the auto_home configuration file is customized per zone. The file is named by zone name. For example, a system with a global zone and a public zone has two auto_home files, auto_home_global and auto_home_public.

Trusted Extensions uses the same mounting interfaces as the Solaris OS:

• To mount files at boot, use the /etc/vfstab file in the labeled zone.

• To mount files dynamically, use the mount command in the labeled zone.

• To automount home directories, use the auto_home_zone-name files.

• To automount other directories, use the standard automount maps. If the automount maps are in LDAP, use LDAP commands to manage them.

Before You Begin

You must be on the client system, in the zone at the label of the files that you want to mount. Unless you are using the automounter, you must be superuser, or be in the System Administrator role. To mount from lower-level servers, the zone must be configured with the net_mac_aware privilege.

1. To NFS mount files in a labeled zone, use the following procedures.

   Most procedures include creating a workspace at a particular label. To create a workspace, see How to Add a Workspace at a Particular Label in Solaris Trusted Extensions User’s Guide.

   • Mount files dynamically.

     In the labeled zone, use the mount command. For an example of mounting files dynamically, see Example 17–3.

   • Mount files when the zone boots

     In the labeled zone, add the mounts to the vfstab file.

     For examples of mounting files when a labeled zone boots, see Example 17–4 and Example 17–5.

   • Mount home directories for systems that are administered with LDAP.

     1. At every label, add the user specifications to the auto_home_zone-name files.

     2. Then, use these files to populate the auto_home_zone-name database on the LDAP server.

     For an example, see Example 17–6.

   • Mount home directories for systems that are administered with files.

     1. Create and populate an /export/home/auto_home_lowest-labeled-zone-name file.

     2. Edit the /etc/auto_home_lowest-labeled-zone-name file to point to the newly populated file.

     3. Modify the /etc/auto_home_lowest-labeled-zone-name file in every higher-level zone to point to the file that you created in Step a.

     For an example, see Example 17–7.

Example 17–3 Mounting Files in a Labeled Zone by Using the mount Command

In this example, the system administrator mounts a remote file system from a public zone. The public zone is on a multilevel server.

After assuming the System Administrator role, the administrator creates a workspace at the label PUBLIC. In that workspace, the administrator runs the mount command.

# zonename
public
# mount -F nfs remote-sys:/zone/public/root/opt/docs  /opt/docs

A single-label file server at the label PUBLIC also contains documents to be mounted:

# mount -F nfs public-sys:/publicdocs  /opt/publicdocs

When the public zone of the remote-sys file server is in the ready or running state, the remote-sys files successfully mount on this system. When the public-sys file server is running, the files successfully mount.

Example 17–4 Mounting Files Read/Write in a Labeled Zone by Modifying the vfstab File

In this example, the system administrator mounts two remote file systems at the label PUBLIC in the local system's public zone when the public zone boots. One file system mount is from a multilevel system, and one file system mount is from a single-label system.

After assuming the System Administrator role, the administrator creates a workspace at the label PUBLIC. In that workspace, the administrator modifies the vfstab file in that zone.

## Writable books directories at PUBLIC
remote-sys:/zone/public/root/opt/docs  - /opt/docs  nfs  no  yes  rw
public-sys:/publicdocs    - /opt/publicdocs  nfs no yes rw

To access the files in the remote labeled zone of the multilevel system, the vfstab entry uses the zone root path of the remote system's public zone, /zone/public/root, as the directory pathname to the directories to mount. The path to the single-label system is identical to the path that would be used on a Solaris system.

In a terminal window at the label PUBLIC, the administrator mounts the files.

# mountall

Example 17–5 Mounting Lower-Level Files in a Labeled Zone by Modifying the vfstab File

In this example, the system administrator mounts a remote file system from a public zone in the local system's internal zone. After assuming the System Administrator role, the administrator creates a workspace at the label INTERNAL, then modifies the vfstab file in that zone.

## Readable books directory at PUBLIC
## ro entry indicates that PUBLIC docs can never be mounted rw in internal zone
remote-sys:/zone/public/root/opt/docs  - /opt/docs  nfs  no  yes  ro

To access the files in the remote labeled zone, the vfstab entry uses the zone root path of the remote system's public zone, /zone/public/root, as the directory pathname to the directories to mount.

From the perspective of a user in the internal zone, the files can be accessed at /opt/docs.

In a terminal window at the label INTERNAL, the administrator mounts the files.

# mountall

Example 17–6 Mounting Labeled Home Directories in a Network That Is Administered by Using LDAP

In this example, the system administrator enables a new user, ikuk, to access her home directory at every label. This site uses two home directory servers, and is administered by using LDAP. The second server contains the home directories for the users jdoe and pkai. The new user is added to this list.

First, after assuming the System Administrator role, the administrator modifies the auto_home_zone-name files in the /etc directory of the global zone to include the new user on the second home directory server.

## auto_home_global file
jdoe   homedir2-server:/export/home/jdoe
pkai   homedir2-server:/export/home/pkai
ikuk   homedir2-server:/export/home/ikuk
*      homedir-server:/export/home/&

## auto_home_internal file
## Mount the home directory from the internal zone of the NFS server
jdoe   homedir2-server:/export/home/jdoe
pkai   homedir2-server:/export/home/pkai
ikuk   homedir2-server:/export/home/ikuk
*      homedir-server:/export/home/&

## auto_home_public
## Mount the home directory from the public zone of the NFS server
jdoe   homedir2-server:/export/home/jdoe
pkai   homedir2-server:/export/home/pkai
ikuk   homedir2-server:/export/home/ikuk
*      homedir-server:/export/home/&

Next, to enable the users to log in at all labels, the administrator repeats these edits for the auto_home_zone-name files at every label.

Finally, after modifying every auto_home_zone-name file on this system, the administrator uses these files to add entries to the LDAP database.

Similar to the Solaris OS, the +auto_home_public entry in the /etc/auto_home_zone-name files directs the automounter to the LDAP entries. The auto_home_zone-name files on other systems on the network are updated from the LDAP database.

Example 17–7 Mounting a Lower-Level Home Directory on a System That Is Administered by Using Files

In this example, the system administrator enables users to access their home directories at every label. The labels at the site are PUBLIC, INTERNAL, and NEEDTOKNOW. This site uses two home directory servers, and is administered by using files. The second server contains the home directories for the users jdoe and pkai.

To accomplish this task, the system administrator defines the public zone NFS home directories in the public zone, and shares this configuration with the internal and needtoknow zones.

First, after assuming the System Administrator role, the administrator creates a workspace at the label PUBLIC. In this workspace, the administrator creates a new file, /export/home/auto_home_public. This file contains all the customized per-user NFS specification entries.

## /export/home/auto_home_public file at PUBLIC label
jdoe   homedir2-server:/export/home/jdoe
pkai   homedir2-server:/export/home/pkai
*      homedir-server:/export/home/&

Second, the administrator modifies the /etc/auto_home_public file to point to this new file.

## /etc/auto_home_public file in the public zone
## Use /export/home/auto_home_public for the user entries
## +auto_home_public
+ /export/home/auto_home_public

This entry directs the automounter to use the contents of the local file.

Third, the administrator similarly modifies the /etc/auto_home_public file in the internal and needtoknow zones. The administrator uses the pathname to the public zone that is visible to the internal and needtoknow zones.

## /etc/auto_home_public file in the internal zone
## Use /zone/public/export/home/auto_home_public for PUBLIC user home dirs
## +auto_home_public
+ /zone/public/export/home/auto_home_public

## /etc/auto_home_public file in the needtoknow zone
## Use /zone/public/export/home/auto_home_public for PUBLIC user home dirs
## +auto_home_public
+ /zone/public/export/home/auto_home_public

When the administrator adds the new user ikuk, the addition is made to the /export/home/auto_home_public file at the PUBLIC label.

## /export/home/auto_home_public file at PUBLIC label
jdoe   homedir2-server:/export/home/jdoe
pkai   homedir2-server:/export/home/pkai
ikuk   homedir2-server:/export/home/ikuk
*      homedir-server:/export/home/&

The higher-level zones read down to obtain the per-user home directories from the lower-level public zone.

How to Troubleshoot Mount Failures in Trusted Extensions

Before You Begin

You must be in the zone at the label of the files that you want to mount. You must be the superuser, or in the System Administrator role.

1. Check the security attributes of the NFS server.

   Use the Security Templates tool in the Solaris Management Console at the appropriate scope. For details, see Initialize the Solaris Management Console Server in Trusted Extensions.

   1. Verify that the IP address of the NFS server is an assigned host in one of the security templates.

      The address might be directly assigned, or indirectly assigned through a wildcard mechanism. The address can be in a labeled template, or in an unlabeled template.

   2. Check the label that the template assigns to the NFS server.

      The label must be consistent with the label at which you are trying to mount the files.

2. Check the label of the current zone.

   If the label is higher than the label of the mounted file system, then you cannot write to the mount even if the remote file system is exported with read/write permissions. You can only write to the mounted file system at the label of the mount.

3. To mount file systems from an NFS server that is running earlier versions of Trusted Solaris software, do the following:

   • For a Trusted Solaris 1 NFS server, use the vers=2 and proto=udp options to the mount command.

   • For a Trusted Solaris 2.5.1 NFS server, use the vers=2 and proto=udp options to the mount command.

   • For a Trusted Solaris 8 NFS server, use the vers=3 and proto=udp options to the mount command.

   To mount file systems from any of these servers, the server must be assigned to an unlabeled template.

Chapter 18 Trusted Networking (Overview)

This chapter describes trusted networking concepts and mechanisms in Trusted Extensions.

• The Trusted Network

• Network Security Attributes in Trusted Extensions

• Trusted Network Fallback Mechanism

• Overview of Routing in Trusted Extensions

• Administration of Routing in Trusted Extensions

• Administration of Labeled IPsec

The Trusted Network

Trusted Extensions assigns security attributes to zones, hosts, and networks. These attributes ensure that the following security features are enforced on the network:

• Data is properly labeled in network communications.

• Mandatory access control (MAC) rules are enforced when data is sent or received across a local network and when file systems are mounted.

• MAC rules are enforced when data is routed to distant networks.

• MAC rules are enforced when data is routed to zones.

In Trusted Extensions, network packets are protected by MAC. Labels are used for MAC decisions. Data is labeled explicitly or implicitly with a sensitivity label. A label has an ID field, a classification or “level” field, and a compartment or “category” field. Data must pass an accreditation check. This check determines if the label is well formed, and if the label lies within the accreditation range of the receiving host. Well-formed packets that are within the receiving host's accreditation range are granted access.

IP packets that are exchanged between trusted systems can be labeled. Trusted Extensions supports Commercial IP Security Option (CIPSO) labels. A CIPSO label on a packet serves to classify, segregate, and route IP packets. Routing decisions compare the sensitivity label of the data with the label of the destination.

Typically on a trusted network, the label is generated by a sending host and processed by the receiving host. However, a trusted router can also add or strip labels while forwarding packets in a trusted network. A sensitivity label is mapped to a CIPSO label before transmission. The CIPSO label is embedded in the IP packet. Typically, a packet sender and the packet's receiver operate at the same label.

Trusted networking software ensures that the Trusted Extensions security policy is enforced even when the subjects (processes) and objects (data) are located on different hosts. Trusted Extensions networking preserves MAC across distributed applications.

Trusted Extensions Data Packets

Trusted Extensions data packets include a CIPSO label option. The data packets can be sent over IPv4 or IPv6 networks.

In the standard IPv4 format, the IPv4 header with options is followed by a TCP, UDP, or SCTP header and then the actual data. The Trusted Extensions version of an IPv4 packet uses the CIPSO option in the IP header for the security attributes.

In the standard IPv6 format, an IPv6 header with extensions is followed by a TCP, UDP, or SCTP header and then the actual data. The Trusted Extensions IPv6 packet includes a multilevel security option in the header with extensions.

Trusted Network Communications

Trusted Extensions supports labeled and unlabeled hosts on a trusted network. LDAP is a fully supported naming service. Various commands and GUIs enable the network to be administered.

Systems that run Trusted Extensions software support network communications between Trusted Extensions hosts and any of the following types of systems:

• Other systems that are running Trusted Extensions

• Systems that are running operating systems that do not recognize security attributes, but do support TCP/IP, such as Solaris systems, other UNIX® systems, Microsoft Windows, and Macintosh OS systems

• Systems that are running other trusted operating systems that recognize CIPSO labels

As in the Solaris OS, Trusted Extensions network communications and services can be managed by a naming service. Trusted Extensions adds the following interfaces to Solaris network interfaces:

• Trusted Extensions adds three network configuration databases, tnzonecfg, tnrhdb, and tnrhtp. For details, see Network Configuration Databases in Trusted Extensions.

• The Trusted Extensions version of the naming service switch file, nsswitch.conf, includes entries for the tnrhtp and tnrhdb databases. These entries can be modified to suit each site's configuration.

  Trusted Extensions uses the LDAP naming service to centrally manage configuration files that define hosts, networks, and users. The default nsswitch.conf entries for the trusted network databases for the LDAP naming service follow:

  # Trusted Extensions tnrhtp: files ldap tnrhdb: files ldap

  The LDAP naming service on a Sun Java System Directory Server is the only fully supported naming service in Trusted Extensions. For information about the use of LDAP on a system that is configured with Trusted Extensions, see Chapter 15, Trusted Extensions and LDAP (Overview).

• Trusted Extensions adds tools to the Solaris Management Console. The console is used to centrally manage zones, hosts, and networks. The network tools are described in Solaris Management Console Tools.

  The Part I, Initial Configuration of Trusted Extensions describes how to define zones and hosts when you configure the network. For additional details, see Chapter 19, Managing Networks in Trusted Extensions (Tasks).

• Trusted Extensions adds commands to administer trusted networking. Trusted Extensions also adds options to the Solaris network commands. For a description of these commands, see Network Commands in Trusted Extensions.

• Trusted Extensions extends the IKE configuration file, /etc/inet/ike/config for labeled IPsec. For more information, see Administration of Labeled IPsec and the ike.config(4) man page

Network Configuration Databases in Trusted Extensions

Trusted Extensions loads three network configuration databases into the kernel. These databases are used in accreditation checks as data is transmitted from one host to another host.

• tnzonecfg – This local database stores zone attributes that are security-related. The attributes for each zone specify the zone label and the zone's access to single-level and multilevel ports. Another attribute handles responses to control messages, such as ping. The labels for zones are defined in the label_encodings file. For more information, see the label_encodings(4) and smtnzonecfg(1M) man pages. For a discussion of multilevel ports, see Zones and Multilevel Ports.

• tnrhtp – This database stores templates that describe the security attributes of hosts and gateways. tnrhtp can be a local database or stored on the LDAP server. Hosts and gateways use the attributes of the destination host and next-hop gateway to enforce MAC when sending traffic. When receiving traffic, hosts and gateways use the attributes of the sender. For details of the security attributes, see Trusted Network Security Attributes. For more information, see the smtnrhtp(1M) man page.

• tnrhdb – This database holds the IP addresses and network prefixes (fallback mechanism) that correspond to all hosts that are allowed to communicate. tnrhdb can be a local database or stored on the LDAP server. Each host or network prefix is assigned a security template from the tnrhtp database. The attributes in the template define the attributes of the assigned host. For more information, see the smtnrhdb(1M) man page.

In Trusted Extensions, the Solaris Management Console has been extended to handle these databases. For details, see Solaris Management Console Tools.

Network Commands in Trusted Extensions

Trusted Extensions adds the following commands to administer trusted networking:

• tnchkdb – This command is used to verify the correctness of the trusted network databases. The tnchkdb command is used whenever you change a security template (tnrhtp), a security template assignment (tnrhdb), or the configuration of a zone (tnzonecfg). The Solaris Management Console tools run this command automatically when a database is modified. For details, see the tnchkdb(1M) man page.

• tnctl – This command can be used to update the trusted network information in the kernel. tnctl is also a system service. A restart with the command svcadm restart /network/tnctl refreshes the kernel cache from the trusted network databases on the local system. The Solaris Management Console tools run this command automatically when a database is modified in the Files scope. For details, see the tnctl(1M) man page.

• tnd – This daemon pulls tnrhdb and tnrhtp information from the LDAP directory. tnd is started at boot time as a service, as in svcadm start /network/tnd. This command also can be used for debugging and for changing the polling interval. For details, see the tnd(1M) man page.

• tninfo – This command displays the details of the current state of the trusted network kernel cache. The output can be filtered by host name, zone, or security template. For details, see the tninfo(1M) man page.

Trusted Extensions adds options to the following Solaris network commands:

• ifconfig – The all-zones interface flag for this command makes the specified interface available to every zone on the system. The appropriate zone to deliver data to is determined by the label that is associated with the data. For details, see the ifconfig(1M) man page.

• netstat – The -R option extends Solaris netstat usage to display Trusted Extensions-specific information, such as security attributes for multilevel sockets and routing table entries. The extended security attributes include the label of the peer, and whether the socket is specific to a zone, or available to several zones. For details, see the netstat(1M) man page.

• route – The -secattr option extends Solaris route usage to display the security attributes of the route. The value of the option has the following format:

  min_sl=label,max_sl=label,doi=integer,cipso

  The cipso keyword is optional and set by default. For details, see the route(1M) man page.

• snoop – As in the Solaris OS, the -v option to this command can be used to display the IP headers in detail. In Trusted Extensions, the headers contain label information.

• ipseckey – In Trusted Extensions, the following extensions are available to label IPsec-protected packets: label label, outer-label label, and implicit-label label. For details, see the ipseckey(1M) man page.

Trusted Network Security Attributes

Network administration in Trusted Extensions is based on security templates. A security template describes a set of hosts that have common protocols and identical security attributes.

Security attributes are administratively assigned to systems, both hosts and routers, by means of templates. The security administrator administers templates and assigns them to systems. If a system does not have an assigned template, no communications are allowed with that system.

Every template is named, and includes the following:

• A host type of either Unlabeled or CIPSO. The protocol that is used for network communications is determined by the host type of the template.

  The host type is used to determine whether to use CIPSO options and affects MAC. See Host Type and Template Name in Security Templates.

• A set of security attributes that are applied to each host type.

For more detail about host types and security attributes, see Network Security Attributes in Trusted Extensions.

Network Security Attributes in Trusted Extensions

Trusted Extensions is installed with a default set of security templates. When a template is assigned to a host, the security values in the template are applied to the host. In Trusted Extensions, both unlabeled hosts and labeled hosts on the network are assigned security attributes by means of a template. Hosts that are not assigned a security template cannot be reached. The templates can be stored locally, or in the LDAP naming service on the Sun Java System Directory Server.

Templates can be assigned directly or indirectly to a host. Direct assignment assigns a template to a particular IP address. Indirect assignment assigns a template to a network address that includes the host. Hosts that do not have a security template cannot communicate with hosts that are configured with Trusted Extensions. For an explanation of direct assignment and indirect assignment, see Trusted Network Fallback Mechanism.

Templates are modified or created by using the Security Templates tool in the Solaris Management Console. The Security Templates tool enforces the completion of the required fields in the templates. Which fields are required is based on the host type.

Each host type has its own set of additional required and optional security attributes. The following security attributes are specified in security templates:

• Host type – Defines whether the packets are labeled with CIPSO security labels or not labeled at all.

• Default label – Defines the level of trust of the unlabeled host. Packets that are sent by an unlabeled host are read at this label by the receiving Trusted Extensions host or gateway.

  The Default label attribute is specific to the unlabeled host type. For details, see the smtnrhtp(1M) man page and the following sections.

• DOI – A positive, non-zero integer that identifies the domain of interpretation. The DOI is used to indicate which set of label encodings applies to a network communication or network entity. Labels with different DOIs, even if otherwise identical, are disjoint. For unlabeled hosts, the DOI applies to the default label. In Trusted Extensions, the default value is 1.

• Minimum label – Defines the bottom of the label accreditation range. Hosts and next-hop gateways do not receive packets that are below the minimum label that is specified in their template.

• Maximum label – Defines the top of the label accreditation range. Hosts and next-hop gateways do not receive packets that are higher than the maximum label that is specified in their template.

• Security label set – Optional. Specifies a discrete set of security labels for a security template. In addition to their accreditation range that is determined by the maximum and minimum label, hosts that are assigned to a template with a security label set can send and receive packets that match any one of the labels in the label set. The maximum number of labels that can be specified is four.

Host Type and Template Name in Security Templates

Trusted Extensions supports two host types in the trusted network databases and provides two default templates:

• CIPSO host type – Intended for hosts that run trusted operating systems. Trusted Extensions supplies the template named cipso for this host type.

  The Common IP Security Option (CIPSO) protocol is used to specify security labels that are passed in the IP options field. CIPSO labels are derived automatically from the data's label. Tag type 1 is used to pass the CIPSO security label. This label is then used to make security checks at the IP level and to label the data in the network packet.

• Unlabeled host type - Intended for hosts that use standard networking protocols but do not support CIPSO options. Trusted Extensions supplies the template named admin_low for this host type.

  This host type is assigned to hosts that run the Solaris OS or other unlabeled operating systems. This host type gives provides a default label and a default clearance to apply to communications with the unlabeled host. Also, a label range or a set of discrete labels can be specified to allow the sending of packets to an unlabeled gateway for forwarding.

The admin_low template provides an example for constructing unlabeled templates with site-specific labels. While the admin_low template is required for the installation of Trusted Extensions, the security settings might not be appropriate for normal system operations. Retain the provided templates without modification for system maintenance and support reasons.

Default Label in Security Templates

Templates for the unlabeled host type specify a default label. This label is used to control communications with hosts whose operating systems are not aware of labels, such as Solaris systems. The default label that is assigned reflects the level of trust that is appropriate for the host and its users.

Because communications with unlabeled hosts are essentially limited to the default label, these hosts are also referred to as single-label hosts.

Domain of Interpretation in Security Templates

Organizations that use the same Domain of Interpretation (DOI) agree among themselves to interpret label information and other security attributes in the same way. When Trusted Extensions performs a label comparison, a check is made as to whether the DOI is equal.

A Trusted Extensions system enforces label policy on one DOI value. All zones on a Trusted Extensions system must operate at the same DOI. A Trusted Extensions system does not provide exception handling on packets that are received from a system that uses a different DOI.

If your site uses a DOI value that is different from the default value, you must add this value to the /etc/system file, and change the value in every security template. For the initial procedure, see Configure the Domain of Interpretation. To configure the DOI in every security template, see Example 19–1.

Label Range in Security Templates

The minimum label and maximum label attributes are used to establish the label range for labeled and unlabeled hosts. These attributes are used to do the following:

• To set the range of labels that can be used when communicating with a remote CIPSO host

  In order for a packet to be sent to a destination host, the label of the packet must be within the label range assigned to the destination host in the security template for that host.

• To set a label range for packets that are being forwarded through a CIPSO gateway or an unlabeled gateway

  The label range can be specified in the template for an unlabeled host type. The label range enables the host to forward packets that are not necessarily at the label of the host, but are within a specified label range.

Security Label Set in Security Templates

The security label set defines at most four discrete labels at which packets can be accepted, forwarded, or sent by the remote host. This attribute is optional. By default, no security label set is defined.

Trusted Network Fallback Mechanism

The tnrhdb database can assign a security template to a particular host either directly or indirectly. Direct assignment assigns a template to a host's IP address. Indirect assignment is handled by a fallback mechanism. The trusted network software first looks for an entry that specifically assigns the host's IP address to a template. If the software does not find a specific entry for the host, it looks for the “longest prefix of matching bits”. You can indirectly assign a host to a security template when the IP address of the host falls within the “longest prefix of matching bits” of an IP address with a fixed prefix length.

In IPv4, you can make an indirect assignment by subnet. When you make an indirect assignment by using 4, 3, 2, or 1 trailing zero (0) octets, the software calculates a prefix length of 0, 8, 16, or 24, respectively. Entries 3 – 6 in Table 18–1 illustrate this fallback mechanism.

You can also set a fixed prefix length by adding a slash (/) followed by the number of fixed bits. IPv4 network addresses can have a prefix length between 1 – 32. IPv6 network addresses can have a prefix length between 1 – 128.

The following table provides fallback address and host address examples. If an address within the set of fallback addresses is directly assigned, the fallback mechanism is not used for that address.

192.168.118.57:cipso

192.168.118.57/32:cipso

192.168.118.57

192.168.118.128/26:cipso

192.168.118.0:cipso

192.168.118.0/24:cipso

192.168.0.0/24:cipso

192.168.0.0:cipso

192.168.0.0/16:cipso

192.0.0.0:cipso

192.0.0.0/8:cipso

192.168.0.0/32:cipso

192.168.118.0/32:cipso

192.0.0.0/32:cipso

0.0.0.0/32:cipso

0.0.0.0:cipso

2001\:DB8\:22\:5000\:\:21f7:cipso

2001:DB8:22:5000::21f7

2001\:DB8\:22\:5000\:\:0/52:cipso

0\:\:0/0:cipso

Note that the 0.0.0.0/32 address matches the specific address, 0.0.0.0. The tnrhdb entry 0.0.0.0/32:admin_low is useful on a system where the literal address, 0.0.0.0, is used as a source IP address. For example, DHCP clients contact the DHCP server as 0.0.0.0 before the server provides the clients with an IP address.

To create a tnrhdb entry on a Sun Ray server that serves DHCP clients, see Example 19–13. Because 0.0.0.0:admin_low is the default wildcard entry, see How to Limit the Hosts That Can Be Contacted on the Trusted Network for issues to consider before removing or changing this default.

For more information about prefix lengths in IPv4 and IPv6 addresses, see Designing Your CIDR IPv4 Addressing Scheme in System Administration Guide: IP Services and IPv6 Addressing Overview in System Administration Guide: IP Services.

Overview of Routing in Trusted Extensions

In Trusted Extensions, routes between hosts on different networks must maintain security at each step in the transmission. Trusted Extensions adds extended security attributes to the routing protocols in the Solaris OS. Unlike the Solaris OS, this Trusted Extensions release does not support dynamic routing. For details about specifying static routing, see the -p option in the route(1M) man page.

Gateways and routers route packets. In this discussion, the terms “gateway” and “router” are used interchangeably.

For communications between hosts on the same subnet, accreditation checks are performed at endpoints only because no routers are involved. Label range checks are performed at the source. If the receiving host is running Trusted Extensions software, label range checks are also performed at the destination.

When the source and destination hosts are on different subnets, the packet is sent from the source host to a gateway. The label range of the destination and the first-hop gateway is checked at the source when a route is selected. The gateway forwards the packet to the network where the destination host is connected. A packet might go through several gateways before reaching the destination.

Background on Routing

On Trusted Extensions gateways, label range checks are performed in certain cases. A Trusted Extensions system that is routing a packet between two unlabeled hosts compares the default label of the source host to the default label of the destination host. When the unlabeled hosts share a default label, the packet is routed.

Each gateway maintains a list of routes to all destinations. Standard Solaris routing makes choices to optimize the route. Trusted Extensions provides additional software to check security requirements that apply to the route choices. The Solaris choices that do not satisfy security requirements are skipped.

Routing Table Entries in Trusted Extensions

The routing table entries in Trusted Extensions can incorporate security attributes. Security attributes can include a cipso keyword. Security attributes must include a maximum label, a minimum label, and a DOI.

For entries that do not provide security attributes, the attributes in the gateway's security template are used.

Trusted Extensions Accreditation Checks

Trusted Extensions software determines the suitability of a route for security purposes. The software runs a series of tests called accreditation checks on the source host, the destination host, and the intermediate gateways.

In the following discussion, an accreditation check for a label range also means a check for a security label set.

The accreditation check verifies the label range and CIPSO label information. The security attributes for a route are obtained from the routing table entry, or from the security template of the gateway if the entry has no security attributes.

For incoming communications, the Trusted Extensions software obtains labels from the packets themselves, whenever possible. Obtaining labels from packets is only possible when the messages are sent from systems that support labels. When a label is not available from the packet, a default label is assigned to the message from trusted networking database files. These labels are then used during accreditation checks. Trusted Extensions enforces several checks on outgoing messages, forwarded messages, and incoming messages.

Source Accreditation Checks

The following accreditation checks are performed on the sending process or sending zone:

• For all destinations, the label of the data must be within the label range of the next hop in the route, that is, the first hop. And, the label must be contained in the first-hop gateway's security attributes.

• For all destinations, the DOI of an outgoing packet must match the DOI of the destination host. The DOI must also match the DOI of all hops along the route, including its first-hop gateway.

• When the destination host is an unlabeled host, one of the following conditions must be satisfied:

  • The sending host's label must match the destination host's default label.

  • The sending host is privileged to perform cross-label communication, and the sender's label dominates the destination's default label.

  • The sending host is privileged to perform cross-label communication, and the sender's label is ADMIN_LOW. That is, the sender is sending from the global zone.

A first-hop check occurs when a message is being sent through a gateway from a host on one network to a host on another network.

Gateway Accreditation Checks

On a Trusted Extensions gateway system,the following accreditation checks are performed for the next-hop gateway:

• If the incoming packet is unlabeled, the packet inherits the source host's default label from the tnrhdb entry. Otherwise, the packet receives the indicated CIPSO label.

• Checks for forwarding a packet proceed similar to source accreditation:

  • For all destinations, the label of the data must be within the label range of the next hop. And, the label must be contained in the security attributes of the next-hop host.

  • For all destinations, the DOI of an outgoing packet must match the DOI of the destination host. The DOI must also match the DOI of the next-hop host.

  • The label of an unlabeled packet must match the destination host's default label.

  • The label of a CIPSO packet must be within the destination host's label range.

Destination Accreditation Checks

When a Trusted Extensions host receives data, the software performs the following checks:

• If the incoming packet is unlabeled, the packet inherits the source host's default label from the tnrhdb entry. Otherwise, the packet receives the indicated CIPSO label.

• The label and DOI for the packet must be consistent with the destination zone or destination process's label and DOI. The exception is when a process is listening on a multilevel port. The listening process can receive a packet if the process is privileged to perform cross-label communications, and the process is either in the global zone or has a label that dominates the packet's label.

Administration of Routing in Trusted Extensions

Trusted Extensions supports several methods for routing communications between networks. In the Security Administrator role, you can set up routes that enforce the degree of security required by your site's security policy.

For example, sites can restrict communications outside the local network to a single label. This label is applied to publicly available information. Labels such as UNCLASSIFIED or PUBLIC can indicate public information. To enforce the restriction, these sites assign a single-label template to the network interface that is connected to the external network. For more details about TCP/IP and routing, see the following:

• Planning for Routers on Your Network in System Administration Guide: IP Services

• Configuring Systems on the Local Network in System Administration Guide: IP Services

• Major TCP/IP Administrative Tasks (Task Map) in System Administration Guide: IP Services

• Preparing Your Network for the DHCP Service (Task Map) in System Administration Guide: IP Services

Choosing Routers in Trusted Extensions

Trusted Extensions hosts offer the highest degree of trust as routers. Other types of routers might not recognize Trusted Extensions security attributes. Without administrative action, packets can be routed through routers that do not provide MAC security protection.

• CIPSO routers drop packets when they do not find the correct type of information in the IP options section of the packet. For example, a CIPSO router drops a packet if it does not find a CIPSO option in the IP options when the option is required, or when the DOI in the IP options is not consistent with the destination's accreditation.

• Other types of routers that are not running Trusted Extensions software can be configured to either pass the packets or drop the packets that include the CIPSO option. Only CIPSO-aware gateways such as Trusted Extensions provides can use the contents of the CIPSO IP option to enforce MAC.

To support trusted routing, the Solaris Express Community Edition routing tables are extended to include Trusted Extensions security attributes. The attributes are described in Routing Table Entries in Trusted Extensions. Trusted Extensions supports static routing, in which the administrator creates routing table entries manually. For details, see the -p option in the route(1M) man page.

The routing software tries to find a route to the destination host in the routing tables. When the host is not explicitly named, the routing software looks for an entry for the subnetwork where the host resides. When neither the host nor the network where the host resides is defined, the host sends the packet to a default gateway, if defined. Multiple default gateways can be defined, and each is treated equally.

In this release of Trusted Extensions, the security administrator sets up routes manually, and then manually changes the routing table when conditions change. For example, many sites have a single gateway that communicates with the outside world. In these cases, the single gateway can be statically defined as the default on each host on the network. Dynamic routing support might be available in future releases of Trusted Extensions.

Gateways in Trusted Extensions

An example of routing in Trusted Extensions follows. The diagram and table show three potential routes between Host 1 and Host 2.

Figure 18–1 Typical Trusted Extensions Routes and Routing Table Entries

• Route #1 can transmit packets within the label range of CONFIDENTIAL to SECRET.

• Route #2 can transmit packets from ADMIN_LOW to ADMIN_HIGH.

• Route #3 does not specify routing information. Therefore, its security attributes are derived from the template in the tnrhtp database for Gateway 5.

Routing Commands in Trusted Extensions

To show labels and extended security attributes for sockets, Trusted Extensions modifies the following Solaris network commands:

• The netstat -rR command displays the security attributes in routing table entries.

• The netstat -aR command displays the security attributes for sockets.

• The route -p command with the add or delete option changes the routing table entries.

For details, see the netstat(1M) and route(1M) man pages.

For examples, see How to Configure Routes With Security Attributes.

Administration of Labeled IPsec

Solaris Trusted Extensions systems can protect labeled network packets with IPsec. The IPsec packets can be sent with explicit or implicit Trusted Extensions labels. Labels are sent explicitly by using CIPSO IP options and implicitly by using labeled IPsec security associations (SAs). Also, IPsec encrypted packets with different implicit labels can be tunneled across an unlabeled network.

For general IPsec concepts and configuration procedures, see Part III, IP Security, in System Administration Guide: IP Services. For Trusted Extensions modifications to IPsec procedures, see Configuring Labeled IPsec (Task Map).

Labels for IPsec-Protected Exchanges

All communications on Trusted Extensions systems, including IPsec-protected communications, must satisfy security label accreditation checks. The checks are described in Trusted Extensions Accreditation Checks.

The labels on IPsec packets that must pass these checks are the inner label, the wire label, and the key management label:

• Application security label – The label of the zone in which the application resides.

• Inner label – The label of the unencrypted message data before IPsec AH or ESP headers have been applied. This label can be different from the application security label when the SO_MAC_EXEMPT socket option (MAC-exempt) or multilevel port (MLP) features are being used. When selecting security associations (SAs) and IKE rules that are constrained by labels, IPsec and IKE use this inner label.

  By default, the inner label is the same as the application security label. Typically, applications at both ends have the same label. However, for MAC-exempt or MLP communication, this condition might not be true. IPsec configuration settings can define how the inner label is conveyed across the network, that is, they can define the wire label. IPsec configuration settings cannot define the value of the inner label.

• Wire label – The label of the encrypted message data after IPsec AH or ESP headers have been applied. Depending on the IKE and IPsec configuration files, the wire label might be different from the inner label.

• Key management label – All IKE negotiations between two nodes are controlled at a single label, regardless of the label of application messages that trigger the negotiations. The label of IKE negotiations is defined in the /etc/inet/ike/config file on a per-IKE rule basis.

Label Extensions for IPsec Security Associations

IPsec label extensions are used on Trusted Extensions systems to associate a label with the traffic that is carried inside a security association (SA). By default, IPsec does not use label extensions and therefore ignores labels. All traffic between two systems flows through a single SA, regardless of the Trusted Extensions label.

Label extensions enable you to do the following:

• Configure a different IPsec SA for use with each Trusted Extensions label. This configuration effectively provides an additional mechanism for conveying the label of traffic that travels between two multilevel systems.

• Specify an on-the-wire label for IPsec encrypted message text that is different from the unencrypted form of the text. This configuration supports the transmission of encrypted confidential data through a less secure network.

• Suppress the use of CIPSO IP options in IP packets. This configuration enables labeled traffic to traverse CIPSO-unaware or CIPSO-hostile networks.

You can specify whether to use label extensions automatically through IKE as described in Label Extensions for IKE, or manually through the ipseckey command. For details on the label extensions features, see the ipseckey(1M) man page.

When using label extensions, SA selection for outbound traffic includes the inner sensitivity label as part of the match. The security label of inbound traffic is defined by the security label of received packet's SA.

Label Extensions for IKE

IKE on Trusted Extensions systems supports the negotiation of labels for SAs with label-aware peers.

You can control this mechanism by using the following keywords in the /etc/inet/ike/config file:

• label_aware – Enables the in.iked daemon's use of Trusted Extensions label interfaces and the negotiation of labels with peers.

• single_label – Indicates that the peer does not support the negotiation of labels for SAs.

• multi_label – Indicates that the peer supports the negotiation of labels for SAs. IKE creates a new SA for each additional label that IKE encounters in the traffic between two nodes.

• wire_label inner – Causes the in.iked daemon to create labeled SAs where the wire label is the same as the inner label. The key management label is ADMIN_LOW when the daemon is negotiating with cipso peers. The key management label is the peer's default label when the daemon is negotiating with unlabeled peers. Normal Trusted Extensions rules are followed for inclusion of the CIPSO IP options in transmitted packets.

• wire_label label – Causes the in.iked daemon to create labeled SAs where the wire label is set to label, regardless of the value of the inner label. The in.iked daemon performs key management negotiations at the specified label. Normal Trusted Extensions rules are followed for inclusion of CIPSO IP options in transmitted packets.

• wire_label none label – Causes behavior similar to wire_label label, except that CIPSO IP options are suppressed on transmitted IKE packets and data packets under the SA.

For more information, see the ike.config(4) man page.

Labels and Accreditation in Tunnel Mode IPsec

When application data packets are protected by IPsec in tunnel mode, the packets contain multiple IP headers.

The IKE protocol's IP header contains the same source and destination address pair as the application data packet's outer IP header.

Trusted Extensions uses the inner IP header addresses for inner label accreditation checks. Trusted Extensions performs wire and key management label checks by using the outer IP header addresses. For information about the accreditation checks, see Trusted Extensions Accreditation Checks.

Confidentiality and Integrity Protections With Label Extensions

The following table explains how IPsec confidentiality and integrity protections apply to the security label with various configurations of label extensions.

You cannot use IPsec AH integrity protections to protect the CIPSO IP option if CIPSO-aware routers might strip or add the CIPSO IP option as a message travels through the network. Any modification to the CIPSO IP option will invalidate the message and cause a packet that is protected by AH to be dropped at the destination.

Chapter 19 Managing Networks in Trusted Extensions (Tasks)

This chapter provides implementation details and procedures for securing a Solaris Trusted Extensions network.

• Managing the Trusted Network (Task Map)

• Configuring Trusted Network Databases (Task Map)

• Configuring Routes and Checking Network Information in Trusted Extensions (Task Map)

• Configuring Labeled IPsec (Task Map)

• Troubleshooting the Trusted Network (Task Map)

Managing the Trusted Network (Task Map)

The following table points to the task maps for common trusted networking procedures.

Configuring Trusted Network Databases (Task Map)