Skip Navigation Links | |
Exit Print View | |
Trusted Extensions Configuration and Administration Oracle Solaris 11 Information Library |
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)
Creating and Managing a Security Policy
Site Security Policy and Trusted Extensions
Computer Security Recommendations
Physical Security Recommendations
Personnel Security Recommendations
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
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 ssh server.
Before You Begin
The remote system is installed with Oracle Solaris and you can access that system.
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.
# 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.
# svcadm restart ssh
# 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.
# vi /etc/pam.conf ... # Default definition for Account management # Used when service name is not explicitly mentioned for account management # # other account requisite pam_roles.so.1 # Enable remote role assumption other account requisite pam_roles.so.1 allow_remote ...
This policy enables username on the client-host system to assume a role on the server.
# vi /etc/pam.conf # Default definition for Account management # Used when service name is not explicitly mentioned for account management # # other account requisite pam_roles.so.1 # Enable remote role assumption other account requisite pam_roles.so.1 allow_remote # other account required pam_unix_account.so.1 # other account required pam_tsol_account.so.1 # Enable unlabeled access to TX system other account required pam_tsol_account.so.1 allow_unlabeled
# cp /etc/pam.conf /etc/pam.conf.site
% 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.conf file.
Troubleshooting
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.
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.
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
DISPLAY=unix:$(echo $DISPLAY|sed -e s/::ffff://|cut -d: -f2)
# 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.
% /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.
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-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.
Remotely log in to the global zone, display the remote global zone, then change 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 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.
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.