|Skip Navigation Links|
|Exit Print View|
|Trusted Extensions Configuration and Administration Oracle Solaris 11.1 Information Library|
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.
Note - Consult your security policy to determine which methods of remote administration are permissible at your site.
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.
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.
# 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.
# svcadm restart ssh
# 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.
# cp /etc/pam.d/other /etc/pam.d/other.orig
# 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.
# 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
% ssh -l root remote-system
# 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.
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.
# 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.
Modify the GNOME Display Manager (gdm) custom configuration file. In the /etc/gdm/custom.conf file, type Enable=true under the [xdmcp] heading,
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.
# svcadm enable xvnc-inetd
# svcadm restart gdm
Wait about one minute for the desktop manager to restart. Then, a VNC client can connect.
# svcs | grep vnc
For the client system, you have a choice of software. You can use VNC software from the Oracle Solaris repository.
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.
% /usr/bin/vncviewer Xvnc-server-hostname
For command options, see the vncviewer(1) man page.
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 ...
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.
desktop $ xhost + remote-sys
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.
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.
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.