JavaScript is required to for searching.
Skip Navigation Links
Exit Print View
Trusted Extensions Configuration and Administration     Oracle Solaris 11 Information Library
search filter icon
search icon

Document Information


Part I Initial Configuration of Trusted Extensions

1.  Security Planning for Trusted Extensions

2.  Configuration Roadmap for Trusted Extensions

3.  Adding the Trusted Extensions Feature to Oracle Solaris (Tasks)

4.  Configuring Trusted Extensions (Tasks)

5.  Configuring LDAP for Trusted Extensions (Tasks)

Part II Administration of Trusted Extensions

6.  Trusted Extensions Administration Concepts

7.  Trusted Extensions Administration Tools

8.  Security Requirements on a Trusted Extensions System (Overview)

9.  Performing Common Tasks in Trusted Extensions (Tasks)

10.  Users, Rights, and Roles in Trusted Extensions (Overview)

11.  Managing Users, Rights, and Roles in Trusted Extensions (Tasks)

12.  Remote Administration in Trusted Extensions (Tasks)

Remote Administration in Trusted Extensions

Methods for Administering Remote Systems in Trusted Extensions

Configuring and Administering Remote Systems in Trusted Extensions (Task Map)

Enable Remote Administration of a Remote Trusted Extensions System

How to Configure a Trusted Extensions System With Xvnc for Remote Access

How to Log In and Administer a Remote Trusted Extensions System

13.  Managing Zones in Trusted Extensions (Tasks)

14.  Managing and Mounting Files in Trusted Extensions (Tasks)

15.  Trusted Networking (Overview)

16.  Managing Networks in Trusted Extensions (Tasks)

17.  Trusted Extensions and LDAP (Overview)

18.  Multilevel Mail in Trusted Extensions (Overview)

19.  Managing Labeled Printing (Tasks)

20.  Devices in Trusted Extensions (Overview)

21.  Managing Devices for Trusted Extensions (Tasks)

22.  Trusted Extensions Auditing (Overview)

23.  Software Management in Trusted Extensions (Reference)

A.  Site Security Policy

Creating and Managing a Security Policy

Site Security Policy and Trusted Extensions

Computer Security Recommendations

Physical Security Recommendations

Personnel Security Recommendations

Common Security Violations

Additional Security References

B.  Configuration Checklist for Trusted Extensions

Checklist for Configuring Trusted Extensions

C.  Quick Reference to Trusted Extensions Administration

Administrative Interfaces in Trusted Extensions

Oracle Solaris Interfaces Extended by Trusted Extensions

Tighter Security Defaults in Trusted Extensions

Limited Options in Trusted Extensions

D.  List of Trusted Extensions Man Pages

Trusted Extensions Man Pages in Alphabetical Order

Oracle Solaris Man Pages That Are Modified by Trusted Extensions



Configuring and Administering Remote Systems in Trusted Extensions (Task Map)

After enabling remote administration before rebooting the remote system into Trusted Extensions, you can configure the system by using Virtual Network Computing (VNC) or the ssh protocol.

For Instructions
Enable remote administration of a Trusted Extensions system.
Enables the administration of Trusted Extensions systems from specified ssh clients.
Enable Virtual Network Computing (VNC).
From any client, uses the Xvnc server on a remote Trusted Extensions system to display the server's multilevel session back to the client.
Log in remotely to a Trusted Extensions system.
Assumes a role on the remote system to administer it.

Note - Consult your security policy to determine which methods of remote administration are permissible at your site.

Enable Remote Administration of a Remote Trusted Extensions System

In this procedure, you enable host-based authentication on an Oracle Solaris remote system before adding the Trusted Extensions feature to it. The remote system is the ssh server.

Before You Begin

The remote system is installed with Oracle Solaris and you can access that system.

  1. On both systems, enable host-based authentication.

    For the procedure, see How to Set Up Host-Based Authentication for Secure Shell in Oracle Solaris Administration: Security Services.

    Note - Do not use the cat command. Copy and paste the public key over an ssh connection. If your ssh client is not an Oracle Solaris system, follow your platform's instructions for configuring an ssh client with host-based authentication.

    After completing this step, you have a user account on both systems that can assume the root role. The accounts are assigned the same UID, GID, and role assignment. You also have generated public/private key pairs and have shared public keys.

  2. On the ssh server, relax ssh policy to enable root to log in remotely.
    # vi /etc/ssh/sshd_config
    ## Permit remote login by root
    PermitRootLogin yes

    A later step limits the root login to a particular system and user.

    Note - Because the administrator is going to assume the root role, you do not need to relax the login policy that prevents remote root login.

  3. On the ssh server, restart the ssh service.
    # svcadm restart ssh
  4. On the ssh server, in root's home directory, specify the host and user for host-based authentication.
    # cd
    # vi .shosts
    client-host username

    The .shosts file enables username on the client-host system to assume the root role on the server, when a public/private key is shared.

  5. On the ssh server, relax the two PAM policies.
    1. Allow remote login by roles.
      # vi /etc/pam.conf
      # Default definition for Account management
      # Used when service name is not explicitly mentioned for account management
      # other   account requisite
      # Enable remote role assumption
      other account requisite allow_remote

      This policy enables username on the client-host system to assume a role on the server.

    2. Allow unlabeled hosts to contact the Trusted Extensions remote system.
      # vi /etc/pam.conf
      # Default definition for Account management
      # Used when service name is not explicitly mentioned for account management
      # other   account requisite
      # Enable remote role assumption
      other   account requisite   allow_remote
      other   account required
      # other   account required
      # Enable unlabeled access to TX system
      other account required allow_unlabeled
    3. Copy your modified pam.conf file to
      # cp /etc/pam.conf /etc/
  6. Test the configuration.
    1. Open a new terminal on the remote system.
    2. On client-host, in a window owned by username, assume the root role on the remote system .
      % ssh -l root remote-system
  7. After the configuration is proved to work, enable Trusted Extensions on the remote system and reboot.
    # svcadm enable -s labeld
    # /usr/sbin/reboot

Example 12-1 Assigning the CIPSO Host Type for Remote Administration

In this example, the administrator is using a Trusted Extensions system to configure a remote Trusted Extensions host. To do so, the administrator uses the tncfg command on each system to define the host type of the peer system.

remote-system # tncfg -t cipso add host= Client-host
client-host # tncfg -t cipso add host= Remote system

Because an unlabeled system can also configure the remote Trusted Extensions host, the administrator leaves the allow_unlabeled option in the remote host's pam.conf file.


When the administrator upgrades to a new release of the Oracle Solaris OS, a new pam.conf file is not installed. For a description of the preserve=true file action on upgrade, see the pkg(5) man page.

How to Configure a Trusted Extensions System With Xvnc for Remote Access

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 server that is running Trusted Extensions, log in to the Xvnc server, then display and work on a multilevel desktop.

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

Before You Begin

You have installed and configured Trusted Extensions on this system that will be used as the Xvnc server. The global zone on this system has a fixed IP address, that is, it is not using the automatic network configuration profile, as described on the netcfg(1M)man page.

This system recognizes the VNC clients by hostname or by IP address. Specifically, the admin_low security template identifies either explicitly or by using a wildcard the systems that can be VNC clients of this server. For more information about configuring the connection securely, see How to Limit the Hosts That Can Be Contacted on the Trusted Network.

If you are currently running in a GNOME session on the console of the future Trusted Extensions Xvnc server, you do not have Desktop Sharing enabled.

You are in the root role in the global zone of the future Trusted Extensions Xvnc server.

  1. Load or update the Xvnc software.
    # packagemanager &

    In the Package Manager GUI, search for “vnc” and choose from the available servers. One option is the TigerVNC X11/VNC server software.

  2. Enable the X Display Manager Control Protocol.

    Modify the GNOME Display Manager (gdm) custom configuration file. In the /etc/gdm/custom.conf file, type Enable=true under the [xdmcp] heading,

  3. Insert the following line in the /etc/gdm/Xsession file around line 27.
    DISPLAY=unix:$(echo $DISPLAY|sed -e s/::ffff://|cut -d: -f2)
  4. Enable the Xvnc server service.
    # svcadm enable xvnc-inetd
  5. Log out all active GNOME sessions on this server.
    # svcadm restart gdm

    Wait about one minute for the desktop manager to restart. Then, a VNC client can connect.

  6. Verify that the Xvnc software is enabled.
    # svcs | grep vnc
  7. On every VNC client of this Xvnc server, install the VNC client software.

    For the client system, you have a choice of software. You can use VNC software from the Oracle Solaris repository.

  8. To display the Xvnc server workspace on a VNC client, perform the following steps:
    1. In a terminal window on the client, connect to the server.
      % /usr/bin/vncviewer Xvnc-server-hostname

      For command options, see the vncviewer(1) man page.

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

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

How to Log In and Administer a Remote Trusted Extensions System

This procedure enables you to use the command line and the txzonemgr GUI to administer a remote Trusted Extensions system.

Before You Begin

The user, role, and role assignment are identically defined on the local and remote systems, as described in Enable Remote Administration of a Remote Trusted Extensions System.

  1. On the desktop system, enable processes from the remote system to display.
    desktop $ xhost + remote-sys
  2. Ensure that you are the user who is identically named on both systems.
  3. From a terminal window, log in to the remote system.

    Use the ssh command to log in.

    desktop $ ssh -X -l identical-username remote-sys
    Password: Type the user's password
    remote-sys $

    The -X option enables GUIs to display.

  4. In the same terminal window, assume the role that is defined identically on both systems.

    For example, assume the root role.

    remote-sys $ su - root
    Password: Type the root password

    You are now in the global zone. You can now use this terminal window to administer the remote system from the command line. GUIs will display on your screen. For an example, see Example 12-2.

Example 12-2 Configuring Labeled Zones on a Remote System

In this example, the administrator uses the txzonemgr GUI to configure labeled zones on a labeled remote system from a labeled desktop system. As in Oracle Solaris, the administrator enables X server access to the desktop system by using the -X option to the ssh command. The user jandoe is defined identically on both systems and can assume the role remoterole.

TXdesk1 $ xhost + TXnohead4
TXdesk1 $ ssh -X -l jandoe TXnohead4
Password: Ins1PwD1
TXnohead4 $

To reach the global zone, the administrator uses the jandoe account to assume the role remoterole. This role is defined identically on both systems.

TXnohead4 # su - remoterole
Password: abcd1EFG

In the same terminal, the administrator in the remoterole role starts the txzonemgr GUI.

TXnohead4 $ /usr/sbin/txzonemgr &

The Labeled Zone Manager runs on the remote system and displays on the local system.

Example 12-3 Logging In to a Remote Labeled Zone

The administrator wants to change a configuration file on a remote system at the PUBLIC label.

The administrator has two options.

Note that if the remote system is running one naming service daemon (nscd) for all the zones, and the remote system is using the files naming service, the password for the remote zone is the password that was in effect when the zone was last booted. If the password for the remote PUBLIC zone was changed, but the zone was not booted after the change, the original password allows access.


If the -X option does not work, you might need to install a package. X11 forwarding is disabled when the xauth binary is not installed. The following command loads the binary: pkg install pkg:/x11/session/xauth.