Chapter 8 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
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. In Trusted CDE, the dtappsession program can remotely launch Trusted CDE actions. Starting in the Solaris 10 5/09 release, 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.
-
Actions in the Trusted_Extensions folder can be started remotely by using the dtappsession command. See How to Remotely Administer Trusted Extensions With dtappsession.
-
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 in Oracle Solaris Trusted Extensions Configuration Guide and Enable Remote Login by a Role in Trusted Extensions in Oracle Solaris Trusted Extensions Configuration Guide.
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 in Oracle Solaris Trusted Extensions Configuration Guide.
-
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.
Caution – 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.
|
Task |
Description |
For Instructions |
|---|---|---|
|
Enable root to remotely log in to a Trusted Extensions system. |
Enables the root user to work remotely from a labeled system. | |
|
Enable a role to remotely log in to a Trusted Extensions system. |
Allows any role to work remotely from a labeled system. | |
|
Enable remote login from an unlabeled system to a Trusted Extensions system. |
Allows any user or role to work remotely from an unlabeled system. | |
|
Log in remotely to a Trusted Extensions system. |
Logs in as a role to a Trusted Extensions system. |
How to Log In Remotely From the Command Line in Trusted Extensions |
|
Administer a system remotely. |
Uses the dtappsession command to administer the remote system with Trusted_Extensions actions. |
How to Remotely Administer Trusted Extensions With dtappsession |
|
From a Trusted Extensions system, uses the Solaris Management Console to administer the remote host. | ||
|
From an unlabeled system, uses the Solaris Management Console to administer remote Trusted Extensions hosts. |
How to Remotely Administer Systems by Using the Solaris Management Console From an Unlabeled System |
|
|
Administer and use a remote system |
From any client, uses the Xvnc server on the remote Trusted Extensions to display a multilevel session back to the client |
How to Use Xvnc to Remotely Access a Trusted Extensions System |
|
Enable specific users to log in to the global zone. |
Uses user and network tools in the Solaris Management Console to enable specific users to access the global zone. |
How to Enable Specific Users to Log In Remotely to the Global Zone in Trusted Extensions |
How to Log In Remotely From the Command Line
in Trusted Extensions
Note –
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 in Oracle Solaris Trusted Extensions Configuration Guide 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 in Oracle Solaris Trusted Extensions Configuration Guide has also been completed.
-
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 Trusted Extensions With dtappsession
The dtappsession program enables an administrator to administer a remote system that is running CDE.
dtappsession is useful when a remote system does not have a monitor. For example, dtappsession is often used to administer domains on large servers. For more information, see the dtappsession(1) man page.
Before You Begin
On a labeled system, you must be in an administrative role in the global zone. On an unlabeled system, you must assume a role that is defined on the remote system. You must then run the remote login from the role's profile shell.
-
(Optional) Create a workspace that is dedicated to the remote session.
To avoid confusion between the remote CDE applications and any local applications, dedicate an administrative role workspace to this procedure. For details, see How to Add a Workspace at a Particular Label in Oracle Solaris Trusted Extensions User’s Guide.
-
Log in to the remote host.
You can use the rlogin command or the ssh command.
$ ssh remote-host
-
Start remote administration.
In the terminal window, type the dtappsession command followed by the name of the local host.
$ /usr/dt/bin/dtappsession local-host
the Application Manager that is running on the remote host displays on the local host. Also, an Exit dialog box appears.
-
Administer the remote host.
If you invoked the remote session from Trusted CDE, you can use actions in the Trusted_Extensions folder.
-
When finished, click the Exit button.
Caution – Closing the Application Manager does not end the login session and is not recommended.
-
In the terminal window, exit the remote login session.
And use the hostname command to verify that you are on your local host.
$ exit $ hostname local-host
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 in Oracle Solaris Trusted Extensions Configuration Guide
-
On the remote system – Enable Remote Login by a Role in Trusted Extensions in Oracle Solaris Trusted Extensions Configuration Guide and Enable the Solaris Management Console to Accept Network Communications in Oracle Solaris Trusted Extensions Configuration Guide
-
On the remote system that is the LDAP server – Configuring the Solaris Management Console for LDAP (Task Map) in Oracle Solaris Trusted Extensions Configuration Guide
-
On the local system, log in as the user who is defined identically on the remote system.
-
Assume the role that you plan to use to administer the system.
-
In the role, start the Solaris Management Console.
For details, see Initialize the Solaris Management Console Server in Trusted Extensions in Oracle Solaris Trusted Extensions Configuration Guide.
-
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.
-
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)
-
-
-
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.
-
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.
Note –Although you can use the Solaris Management Console to run dtappsession, the simplest way to use dtappsession is described in How to Remotely Administer Trusted Extensions With dtappsession.
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.
Note –
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 in Oracle Solaris Trusted Extensions Configuration Guide.
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.
-
Enable the local X server to display the remote Solaris Management Console.
# xhost + TX-SMC-Server # echo $DISPLAY :n.n
-
On the local system, become the user who can assume a role for the Solaris Management Console.
# su - same-username-on-both-systems
-
As that user, log in to the remote server as the role.
$ rlogin -l same-rolename-on-both-systems TX-SMC-Server
-
Make sure that the environment variables that the Solaris Management Console uses have the correct values.
-
Set the value of the DISPLAY variable.
$ DISPLAY=local:n.n $ export DISPLAY=local:n.n
-
Set the value of the LOGNAME variable to the user name.
$ LOGNAME=same-username-on-both-systems $ export LOGNAME=same-username-on-both-systems
-
Set the value of the USER variable to the role name.
$ USER=same-rolename-on-both-systems $ export USER=same-rolename-on-both-systems
-
-
In the role, start the Solaris Management Console from the command line.
$ /usr/sbin/smc &
-
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.
-
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.
-
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.
-
To enable remote login from a labeled zone into the global zone, do the following.
-
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.
-
Read the tnzonecfg changes into the kernel.
# tnctl -fz /etc/security/tsol/tnzonecfg
-
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.
-
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.
-
Create the Xservers configuration directory.
# mkdir -p /etc/dt/config
-
Copy the /usr/dt/config/Xservers file to the /etc/dt/config directory.
# cp /usr/dt/config/Xservers /etc/dt/config/Xservers
-
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.
-
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
-
-
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
-
In a terminal window on a vnc client, connect to the server.
% /usr/bin/vncviewer Xvnc-server-hostname
-
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 Oracle 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.
- © 2010, Oracle Corporation and/or its affiliates