This content is submitted by a BigAdmin user. It has not been reviewed for technical accuracy by Sun Microsystems, though it may have been lightly edited to improve readability. If you find an error or would like to comment on the article, please contact the submitter or use the comment field at the bottom of the article.
Community submissions may not follow Sun trademark guidelines. For information on Sun trademarks, please see http://www.sun.com/suntrademarks/.
Overview of Solaris Trusted Extensions for Corporate Deployments
Robert Bailey, June 2008
This article provides a layman's overview of deploying Solaris Trusted Extensions in a corporate environment, and it describes the interactions
between systems that have this technology and systems that do not.
Note: The information here applies to the Solaris 10 11/06 Operating System or later.
Solaris Trusted Extensions software takes the concept of local and global zones and puts a security framework around it, while increasing
the amount of information communicated between those zones. This framework controls which users can access a zone, what hosts can talk to a zone,
and what a zone's relationship is to the other local and remote zones.
As of the Solaris 10 11/06 OS, trusted components are packages installed into a standard distribution of the Solaris OS; trusted components are no longer a separate OS distribution.
When Solaris Trusted Extensions software is installed, the following capabilities, among others, exist:
Additional features are added to the zone.xml feature sets.
Auditing components are automatically turned on for C2 Basic Security Module (C2/BSM).
New settings are the in user_attr file.
ifconfig supports the all-zones feature.
Routed, automountd -lofs is used for user home directory mounts.
Business Terminology Versus Security Terminology
Some of the terminology used with security models can be different from common business terms related to security levels. An example of this would be that
in a business, a public-access server is considered to be the highest level of security, but in a security model, a public-access server would be the
least trusted system. Since Solaris Trusted Extensions originated from government requirements, the terminology used in Solaris Trusted Extensions
documentation complies more with security model terminology than with business model terminology.
Think of it this way...when a zone is public facing, you want information on it that is appropriate for public consumption; you would not want
your CEO's personal information on it. Therefore, the CEO's personal information will be on your most RESTRICTED security clearance server and zone,
and the information that everyone can view is on your least trusted, most accessed, PUBLIC system.
About Applications on Systems That Run Solaris Trusted Extensions
Because different clearance levels are basically different zones, your application has to be able to run in a local zone. There are
some adjustments you can make to share data between clearance levels and zones; however, this should be done only for "upgrading" or
"downgrading" information.
Potential Uses for Solaris Trusted Extensions
DMZ hosted servers
Firewall systems
Web servers in any environment
A contractor or restricted-visitor network or host access
Sensitive internal data
Secured software distribution
Any environment that requires upgrading or downgrading information
Securities and Exchange Commission (SEC) requirements for environment isolation
Business Challenges for Solaris Trusted Extensions
The following challenges are more of an issue in a business environment where Solaris Trusted Extensions systems are not the norm
and systems must function with hosts that have a standard OS deployment:
As of the Solaris 10 5/08 release ("Update 5"), Trusted Extensions software recognizes labels on NFS Version 3 (NFSv3) and NFSv4. Before this, only NFSv4 was supported. For NFSv4, unless the NFS server is running Solaris Trusted Extensions, mapping out which zones can have access to which shares on an NFS server might be a challenge.
Systems not running Solaris Trusted Extensions need to have a mapping file configured that tells the Solaris Trusted Extensions system to which
local zone communications will be forwarded when sending to or receiving from that remote system. Since a remove system can be mapped only to
a single zone, careful access planning is needed.
Lots of clearance levels equal lots of local zones, which currently implies patching challenges with zones.
Operational changes and training can be a challenge, especially around "why can't I ping the server or log in?" questions.
You will probably want to review using a workstation with Solaris Trusted Extensions to help manage multiple servers using Solaris Trusted Extensions. This is due to the Common Desktop Environment/Sun Java Desktop System integration and the ability to connect to all local zones on the Solaris Trusted Extensions servers.
Dare I say it? Political discussions over labeling names and classifications might be a challenge.
Technical Aspects of a Solaris Trusted Extensions Configuration
The global zone is considered the "controller" zone where access is permitted only for system administration. Users use each of the
local zones for general usage based on their clearance levels. These clearance levels are stored in LDAP or /etc/user_attr
in the global zone.
The Name Service Cache is used by each local zone to look up user, password, and host name information. This allows
non-Solaris Trusted Extensions services, such as LDAP and DNS, to provide information to a local zone when the default clearances
do not line up. The global zone is mapped to the DNS and LDAP services, and it passes information to each local zone using nscd.
This process is needed when your DNS and or LDAP server is not a Solaris Trusted Extensions system.
Note: The use of nscd results in a potential failure of common commands, such as
nslookup. However, using the getent hosts <hostname> command
resolves the host name and IP address when it is run from a local zone that does not map to the DNS server. The same is true
for some other services, such as getent passwd <user>.
Solaris Trusted Extensions zones can share a single IP address (through the all-zones option), or they can have their own dedicated IP
addresses. All IP traffic is governed by the global zone and forwarded to the appropriate individual local zone based on the clearance
of the local zone and the remote zone.
When connecting to a Solaris Trusted Extensions system from a non-Solaris Trusted Extensions system, the
non-Solaris Trusted Extensions system must match a specific network label. The default clearance for that non-Solaris Trusted Extensions system
determines which local zone the connection attaches to.
Example:
If hostname-A is not a Solaris Trusted Extensions system and has a network label defaulting to PUBLIC, any connection
coming in from hostname-A is directed to the local zone with the PUBLIC label.
These network labels can be based on the subnet or a specific IP address.
A non-trusted system can have only a single default label. That host cannot be a member of multiple labels. So if you want a host to be
able to connect to a Solaris Trusted Extensions host at all potential clearances or zones on that host, the remote host must be configured
with Solaris Trusted Extensions and have the same label_encodings file.
About Labels
How Many Types of Labels Are There?
There are two basic types of labels:
A label applied to a host
A label applied to a zone
In the Solaris Trusted Extensions documentation, there are Classifications, Sensitivity Labels, and Information Labels, but this article
is an attempt to describe Solaris Trusted Extensions in high-level terms and concepts. So, a zone has a label applied to it and all file
systems mounted in it, and processes executed in that zone are run as that label. This label equals a specific security clearance.
Example Label Types
Classification Labels and Sensitivity Labels are associated with a specific zone.
When users log in to a zone, any processes and files that are accessed or created in that zone are set to the Classification and
Sensitivity Label assigned to that zone. There are some exceptions, but that is beyond the scope of this article.
Network label types, such as CIPSO and unlabeled, are associated with a specific zone and a specific remote host.
When a remote host that does not have Solaris Trusted Extensions connects to a host that has Solaris Trusted Extensions, the network
label assigned to that remote host dictates which Solaris Trusted Extensions zone receives the connection. This network label is defined in
the tnrhtp database and will be type unlabeled with a def_label
attribute set to the label that the remote host will always connect to. When the remote host does not have Solaris Trusted Extensions,
the binding of a remote host to a specific single label means that the remote host will be able to connect only to a single zone on the Solaris
Trusted Extensions system.
A type CIPSO network label is defined in the tnrhtp database and identifies a remote host
as a system running Solaris Trusted Extensions. Note that in order for the two Solaris Trusted Extensions systems to communicate properly, the
label_encodings files on each system must match.
Default Installed Label Definitions for a Host or Zone
ADMIN_HIGH
ADMIN_LOW
CIPSO
Ranges in the global zone are from ADMIN_LOW to ADMIN_HIGH.
The network label is ADMIN_LOW for 0.0.0.0 or all networks.
Definition Files for Labels
Site labels: defined in /etc/security/tsol/label_encodings
Matching zones to labels: in /etc/security/tsol/tnzonecfg
Network to label matching: in /etc/security/tsol/tnrhtp
Defining network labels: in /etc/security/tsol/tnrhdb
In Summation
When you create a local zone, it must be matched to a label/clearance defined in the label_encodings file.
These zones are matched to a specific label defined in the label_encodings file under /etc/security/tsol.
Each label has a ranking number from 1 to N (the higher the number, the greater the level of clearance), and is matched to a label name that
you define in the same file. No two zones on a host can have the same label; however, they can have equal levels of clearance allowing communication.
Common examples are RESTRICTED, INTERNAL, and PUBLIC. The global
zone works as an "umpire" for these labeled zones and itself. This framework not only includes and excludes who can log in to a clearance/zone but
what hosts can talk to that zone.
IP traffic allowed over the global zone's Ethernet interface for one
zone or clearance can be blocked on the same interface for a zone or
clearance that the remote user or host does not have access to.
The global zone has, by default, the label range of ADMIN_LOW to ADMIN_HIGH.
So, to use Solaris Trusted Extensions, you need to define the labels you will use, for example, RESTRICTED,
INTERNAL, and PUBLIC, in the label_encodings file, then
match each label to a specific local zone, and finally, decide on what hosts can talk to the labels you created.
Note: After installing Solaris Trusted Extensions, there are a number of example label_encodings files
to help you pick your own labeling plan.
Remote hosts are marked with network labels that contain either unlabeled or CIPSO types.
In the following example, every remote host labeled as extranet automatically has its connections, bound for
this Solaris Trusted Extensions host, forwarded to the local zone with the clearance of RESTRICTED. Upon review,
note that only the host 192.168.15.97 and any host on the 192.223.207.0 subnet will be directed to the local zone with the clearance of
RESTRICTED. Also note that 192.168.15.97 and hosts on 192.223.207.0 cannot communicate with any other zone
on this Solaris Trusted Extensions system.
A final comment about this example is that in the tnrhtp database, I did not use the hex equivalent of the label.
Using the hex equivalent of a label is recommended. ASCII was used here in order to make the examples clearer.
The tnrhdb database:
# CIPSO - who is a TX System
127.0.0.1:cipso
192.168.15.78:cipso
192.168.15.94:cipso
#
# ADMIN_LOW - list of servers that are not running Solaris
# Trusted Extensions and need access to my global zone
192.168.15.1:admin_low # DNS Server
192.168.15.100:admin_low # Management Server
#
# SSH Allowed Remote
192.168.15.79:extranet
192.223.207.0:extranet
#
# All others can view my web site zone, but that is all.
0.0.0.0:world
The tnrhtp database:
Note: The ADMIN_LOW and ADMIN_HIGH labels match the global zone.
Limitations: Good or Bad
Solaris Trusted Extensions software does not support Branded Zones on a system that has Solaris Trusted Extensions.
Documentation for Solaris Trusted Extensions focuses on deployment within LDAP environments, and therefore it may require additional effort to identify how to properly deploy in a non-LDAP environment. Please note that as the product matures, the documentation improves, and this limitation may not be applicable to the Solaris 10 5/08 release ("Update 5").
The author's web site, which has personal examples of using web browsers with
restricted zones along with blog feedback
About the Author
Robert Bailey of Raleigh, North Carolina, has worked as a system administrator at a financial company for over 10 years, with a focus on high availability Veritas Cluster Server, Oracle Real Application Clusters 10g, and Veritas Application Director, and secondary
ventures in Solaris security.
The information and links on this page have been provided by a BigAdmin user. The submitter is solely responsible for such information and links. Sun is not responsible for the availability of external sites or resources, and does not endorse and is not responsible or liable for any content, advertising, products, or other materials on or available from such sites or resources. Sun will not be responsible or liable, directly or indirectly, for any actual or alleged damage or loss caused by or in connection with use of or reliance on the information posted here, or goods or services available on or through any external site or resource.
Comments (latest comments first)
Discuss and comment on this resource in the BigAdmin Wiki
Unless otherwise licensed, code in all technical manuals herein (including articles, FAQs, samples) is provided under this License.
Print-friendly Version
