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.

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 Secure Shell server.

Before You Begin

The remote system is installed with Oracle Solaris and you can access that system. You must be in the root role.

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 11.1 Administration: Security Services.

   ---

   Note - Do not use the cat command. Copy and paste the public key over a Secure Shell connection. If your Secure Shell client is not an Oracle Solaris system, follow your platform's instructions for configuring a Secure Shell 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 Secure Shell server, relax ssh policy to enable root to log in remotely.

   # pfedit /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 Secure Shell server, restart the ssh service.

   # svcadm restart ssh

4. On the Secure Shell server, in root's home directory, specify the host and user for host-based authentication.

   # cd
   # pfedit .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 Secure Shell server, relax the two PAM policies.
   1. Copy the /etc/pam.d/other to /etc/pam.d/other.orig.

      # cp /etc/pam.d/other /etc/pam.d/other.orig

   2. Modify the pam_roles entry to allow remote login by roles.

      # pfedit /etc/pam.d/other
      ...
      # Default definition for Account management
      # Used when service name is not explicitly mentioned for account management
      # ...
      #account requisite    pam_roles.so.1
      # Enable remote role assumption
      account requisite    pam_roles.so.1   allow_remote
      ...

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

   3. Modify the pam_tsol_account entry to allow unlabeled hosts to contact the Trusted Extensions remote system.

      # pfedit /etc/pam.d/other
      # Default definition for Account management
      # Used when service name is not explicitly mentioned for account management
      # ...
      #account requisite    pam_roles.so.1
      # Enable remote role assumption
      account requisite    pam_roles.so.1   allow_remote
      #
      account required     pam_unix_account.so.1
      #account required     pam_tsol_account.so.1
      # Enable unlabeled access to TX system
      account required     pam_tsol_account.so.1  allow_unlabeled

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=192.168.1.12 Client-host

client-host # tncfg -t cipso add host=192.168.1.22 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.d/other file.

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.

   If you are unable to open the GUI, add the local root account to the X server access control list. Run this command as the user who logged in to the X server.

   % xhost +si:localuser:root

   For more information, see the xhost(1) and Xsecurity(5) man pages.

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,

   [xdmcp]
   Enable=true

3. Insert the following line in the /etc/gdm/Xsession file around line 27.

   ---

   Tip - Save a copy of the original Xsession file before making the change.

   ---

   DISPLAY=unix:$(echo $DISPLAY|sed -e s/::ffff://|cut -d: -f2)

   The files in Step 2 and Step 3 are marked with the package attribute preserve=true. For information about the effect this attribute has on your modified files during package upgrades and package fixes, see the pkg(5) man page.

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. (Optional) Audit VNC connections.

   For information about preselecting audit events per system and per user, see Configuring the Audit Service (Tasks) in Oracle Solaris 11.1 Administration: Security Services.

9. 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.

Example 12-2 Using Vino to Share a Desktop in a Test Environment

In this example, two developers are using the GNOME Vino service to share the display from the Launch → System → Preferences → Desktop Sharing menu. In addition to the preceding steps, they relax Trusted Extensions policy by enabling the XTEST extension.

# pfedit /usr/X11/lib/X11/xserver/TrustedExtensionsPolicy
## /usr/X11/lib/X11/xserver/TrustedExtensionsPolicy file
...
#extension XTEST
extension XTEST
...

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-3.

Example 12-3 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-4 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.

• Remotely log in to the global zone, display the remote global zone workspace, then change the workspace to the PUBLIC label, open a terminal window, and edit the file

• Remotely log in to the PUBLIC zone by using the ssh command from a PUBLIC terminal window and then edit the file

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 PUBLIC zone is the password that was in effect when it 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.

Troubleshooting

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.