Yes.

In either case, on the Trusted Extensions system, you must assign a label (security template) to the IP address of the non-Trusted Extensions system. Non-Trusted Extensions systems are also called unlabeled systems because they do not send CIPSO labels in network packets.

An older version of the mountd daemon handles the mount request, so the Trusted Extensions system is treated as unlabeled.

NFSv3 and NFSv4.

• In the Solaris 10 11/06 and Solaris 10 8/07 releases, a Trusted Extensions NFS server must be running NFSv4.

• Starting in the Solaris 10 5/08 release, a Trusted Extensions NFS server can be running NFSv3 or NFSv4.

You cannot NFS mount a file system into the global zone with read-write permissions.

Unlabeled clients that use the admin_low security template, which is the default template for unlabeled systems, are less trusted than labeled clients that run at the ADMIN_LOW label.

For example, consider the DNS server. On a labeled server, all zones use the nscd daemon in the global zone. This daemon communicates with the DNS server at the label ADMIN_LOW. However, the DNS server is not trusted in any other regard, so it should not have access to the global zone.

Similarly, the pam_tsol_account module does not allow remote logins from an unlabeled system that is using the admin_low security template.

Files that are LOFS-mounted in the global zone can be modified, that is, have read-write permissions, in the global zone.

Always create a security template by using the Solaris Management Console. This GUI prevents you from specifying an invalid label. The CIPSO protocol limits network traffic to 240 compartment bits. Therefore, a valid CIPSO label cannot have compartment bits that are higher than 239 (the range is from 0 to 239, that is, 240 compartment bits).

Alternatively, you could modify your label_encodings file to limit the compartment bits to the range between 0 and 239.

You do not add this privilege to server. The priv_mac_exempt privilege is for use on a client. In the global zone on a client, run the following command:

# ppriv -e -M

In the zone where you want to mount the lower-labeled zone, apply the net_mac_aware process attribute to the mount. For example, as root in the internal zone, mount the /export/stuff directory from the public zone:

# ppriv -e -M /usr/lib/fs/nfs_mount hostname:zone/public/export/stuff

Starting in the Solaris 10 8/07 release, read-down NFS mounts work by default.

Perhaps your home directory in the global zone has bad permissions or is not owned by you. To debug the problem, do the following:

1. Log in as root. In the global zone, open a terminal window and view the home directory of your username.

2. Verify that the home directory is owned by you.

3. Verify that the home directory is mounted.

4. Examine the file ~/.dt/sessions/lastsession. The file's contents is probably /usr/dt/config/Xsession. However, the contents should be /usr/dt/config/Xsession.tjds. If this file in your home directory is not owned and writable by you, that is why the default desktop is not the trusted version of the Sun Java Desktop System, Trusted JDS.

Workaround - Fix the ownership of all files and directories in your global zone home directory so that they are owned by you. You could also delete all files and directories under the ~/.dt directory and start over.

The LDAP server software is not part of Solaris installation nor is it part of the Trusted Extensions packages. You can download the server software from the Sun Products site.

In the Device Allocation Manager, allocate the DVD drive and respond y to mount the disk.

If you have an incorrect entry in the device_allocate and device_maps entries for the DVD drive, run the mkdevalloc command with the system_labeled argument and try again.

# /usr/sbin/mkdevalloc system_labeled

By default, remote login to labeled zones does not work. Consider the following:

• The remote client must have the same label as the labeled zone. Having the same label can be accomplished in one of two ways:

  • If the remote system is running Trusted Extensions, then each system must assign a CIPSO template to the other.

  • If the remote system is not running Trusted Extensions, then the Trusted Extensions system must have associate the remote system with an unlabeled security template. This security template must have the same default label as the zone label.

• The labeled zone must be able to locally authenticate the account. Note that the shadow file is not cached by the nscd daemon, so the global zone data is not available to the labeled zone by means of nscd. If the labeled zone is an LDAP client, then the password is provided by the LDAP server. If you are not using LDAP, then the labeled zone needs a copy of the global zone's passwd and shadow entries. For a labeled zone to obtain a copy of these files, you must loopback mount the passwd and shadow files from the global zone.

For specific procedures, see the following:

• To mount files in a labeled zone, see How to NFS Mount Files in a Labeled Zone in Solaris Trusted Extensions Administrator’s Procedures.

• To loopback mount files into a labeled zone, see How to Loopback Mount a File That Is Usually Not Visible in a Labeled Zone in Solaris Trusted Extensions Administrator’s Procedures.

• To enable remote login to a labeled zone, see Administering Trusted Extensions Remotely (Task Map) in Solaris Trusted Extensions Administrator’s Procedures.

The full error message is the following:

zoneadm: zone 'public': zone_create failed: File exists
     zoneadm: zone 'public': call to zoneadmd failed

You probably did not add the Default Label View to the LOCAL DEFINITIONS section of the /etc/security/tsol/label_encodings file during the configuration process.

1. To verify the Default Label View, check the definition of the public zone in the tnzonecfg file. The following entry indicates that you skipped the step:

   public:ADMIN_LOW:0::

2. Add this entry to the label_encodings file:

   Default Label View is Internal;

3. Then, open the Solaris Management Console, verify the definition of the public zone, and try again to boot the public zone.

The txzonemgr script in the Solaris 10 11/06 and Solaris 10 8/07 releases does not support assigning IPv6 addresses to zones. However, information about IPv6 addresses is covered in the following documentation:

• Add a Network Interface to an Existing Labeled Zone in Solaris Trusted Extensions Installation and Configuration.

• You can also use the txzonemgr script for the initial zone setup, and then run the zonecfg command directly. Assuming that you want to assign a unique IPv6 address to each zone, you need to create a script similar to the following:

  IF=bge0
  #for public's ipv6
  zonecfg -z public <<EOF
  add net
  set address=2001::1/64
  set physical=$IF
  end
  commit
  EOF
  =view

  If you first assign the host name's address in the /etc/hosts file, you can use the host name instead of the IP address in the set address subcommand.

• Starting in the Solaris 10 8/07 release, the /etc/hosts and /etc/inet/ipnodes files are unified and are symbolic links to each other. Routing must be done in the global zone as is discussed in the Trusted Extensions and Zones forums.

• If you want to send CIPSO packets over IPv6, follow the steps in Enable IPv6 Networking in Trusted Extensions in Solaris Trusted Extensions Installation and Configuration.

Untrusted applications in labeled zones can use the cut-and-paste protocol if the user is authorized and confirms the selection. No labeled information is passed between the holder and the requestor.

However, when you are upgrading or downgrading files by using drag and drop, the clients must be trusted. The drop site must determine the label of the source client. So, to use the multilevel drag-and-drop protocol, both the source client and the destination client must be trusted.

Labeled zones do not communicate directly with the DNS servers because the labels do not match, such as ADMIN_LOW for DNS servers and PUBLIC for a zone. Therefore, in a labeled zone that directly calls the DNS name service, commands such as host machine-name, nslookup, or dig, fail.

However, commands that use the name service switch, such as getent(1M), gethostbyname(3NSL), and others, succeed. For these commands, the query is resolved in the global zone by using the nscd daemon as a proxy.

% zonename
public
% getent hosts mailhost
192.168.111.12  mailhost.subnet.example.com
192.168.112.9   mailhost.subnet.example.com

The getent command successfully retrieves DNS server information when you're in a labeled zone because nscd is a door service that runs in the global zone with its door file mounted into the local zone.

Your tnzonecfg file appears to be correct. In your tnzonecfg file, the MLP declaration in the public-facing zone is as follows:

global:ADMIN_LOW:1:111/tcp;111/udp;515/tcp;631/tcp;2049/tcp;6000-6003/ 
tcp:6000-6003/tcp
pub-tx01:0x0002-08-08:0::80/tcp

The full text of your error is the following:

(13)Permission denied: make_sock: could not bind to address [::]:80
no listening sockets available, shutting down
Unable to open logs

To debug the problem, verify the following:

• The svc program has the net_bindmlp privilege in its limit set.

• In the public-facing zone, the output of ifconfig -a shows an all-zones interface that the zone can use.

• The socket() call did not fail.

• The svc program is binding to the correct IP address.

• No other process is already bound to port 80.

There are several possible causes. To debug the problem, do the following:

1. From the global zone, log in to the zone as root.

   # zonename
   global
   # zlogin zone

2. Verify that the zone is healthy:

   zone# svcs -x

3. Verify that nothing is seriously wrong. The following message indicates that nothing is seriously wrong:

   zone# svcs -x
   svc:/application/print/server:default (LP print server)
    State: disabled since date
   Reason: Disabled by an administrator.
      See: http://sun.com/msg/SMF-8000-05
      See: lpsched(1M)
   Impact: 2 dependent services are not running.  (Use -v for list.)

4. Set the DISPLAY variable to the host name of your global zone:

   zone# echo $DISPLAY
   :number.number
   zone# DISPLAY=global-zone-hostname:number.number
   zone# export DISPLAY

5. Open a terminal window in the zone:

   zone# /usr/dt/bin/dtterm

6. Verify that the terminal window is properly labeled.

7. Become the user:

   zone# su - user

8. Verify that you obtain a valid context, including a valid home directory.

9. Verify that the host name of the public zone is not public.

   The host name must be a valid name that is defined in the global zone's /etc/hosts or /etc/inet/ipnodes file. The public zone's instances of these files is ignored.

   Note - Starting in the Solaris 10 8/07 release, the ipnodes file is removed. The hosts file is used for IPv6 addresses.