You Trust Trusted Solaris 8?
Peter Baer Galvin
In the old days, Trusted Solaris had a reputation of being difficult
to manage. In fact, the user base consisted of government sites
and other facilities where security was required. Trusted Solaris
8 aims to change all that, with a goal of being very Solaris-like,
but with manageable security enhancements. How well does it succeed?
Very well, as it turns out. I took it for a spin and liked the drive-ability.
Trusted Solaris 8 (TS8) arrived not long after standard Solaris
8 (S8OE), making it a viable alternative to the standard. Previous
Trusted Solaris releases had a significant lag behind their counterparts.
This helped contribute to the lack of interest in the secure alternative
at sites where it was not required.
Security has become de rigueur as interconnections multiply almost
as fast as security threats. Companies are connecting to the Internet,
and to each other, like never before. Computer attacks are becoming
more sophisticated, to the point where firewalled connections are
the beginning, rather than the end, of a security implementation.
The popularity of Solaris increases the demand for security solutions
on the platform. That is one of the reasons I wrote the Solaris
Security FAQ a few years ago and have since maintained it (with
an update in the offing).
Many sites are adopting TS8 due to the increasing demand for security
in commercial environments. Financial and banking, service providers,
and the healthcare industry are all taking advantage of the enhanced
security found in Trusted Solaris. TS8 is apparently the only operating
system with EAL4 LSPP certification that is 64-bit. It has a firm
lead in B1-equivalent security, leaving little option for those
who want a fast, general-purpose but highly secure OS.
TS8 is a big improvement on TS2.5.1. Recompilation is no longer
required for applications to run within this environment. Privileges
and rights might need to be granted for a given application to run
properly, but it is now much easier to run an application on TS8
than on previous TS releases. Kernel-modifying programs can be a
challenge because the kernel is not the same as on S8, but that
includes a small subset of available applications.
Of course there is a price to pay, and it is in the form of money.
TS8 is not free, unlike S8. The base price is $2495 for one to two
CPUs for either SPARC or Intel systems. TS8 on Intel is a nice solution
for those sites without a Sun presence but wanting more secure servers.
For example, a WinTel site may want a secure LDAP server for user
authentication, and could convert an existing PC to TS8.
For TS8 to become mainstream, it needs to increase the security
of the Solaris 8 Operating Environment (S8OE) while being compatible
with the S8 application base, and being manageable by systems administrators
familiar with S8OE. Much of the success of TS8 will depend on success
in these aspects. With that in mind, I took the plunge and installed
TS8 looks a lot like standard S8OE. In fact, it is a superset
of S8OE. The code base is the same, and TS8 adds extensions to the
core S8 to dramatically increase the ability to secure the system.
For example, TS8 4/01 is forthcoming and is based on the Solaris
8 4/01 release. In general, a Trusted Solaris release should occur
within six months of the standard Solaris release. The code is actually
ready rather quickly, but the independent security testing for certification
adds a delay that is outside of Suns release timetable control.
TS8 enhances both external and internal security. Misuse of the
system by authorized users is a main source of security violations.
TS8 helps prevent violations by enabling administrators to implement
a security policy. The policy can control access to and handling
TS8 provides many features, including:
Privileges (granted to a process) and Authorizations (granted to a
user) are part of Role-Based Access Control. They provide a means
for users and processes to go beyond their label ranges and perform
normally disallowed tasks. Administrators must log in under their
own accounts, and then assume roles that give them access
to privileged commands. (RBAC was previously covered in the Solaris
Corner online at: http://www.samag.com/documents/sam0108p.)
In fact, the S8OE RBAC is based on the TS8 RBAC feature. There are
four default roles: security administrator, systems administrator,
primary administrator (who creates rights profiles and has the most
abilities on the system), and oper (the operator). Note that one user
can have more than one role, when the situation justifies it. About
60% of the UNIX exploits are root exploits, which is why RBAC is so
- Meeting requirements for B1+ systems
- Providing labeled security
- Supporting the concept of least privilege
- Supporting role-based access control (RBAC)
- Limiting access to system data and resources via labels
(see below) set on programs, files, directories, devices, and
- Eliminating the power of superuser (root), and dividing those
functions into multiple roles
- Augmenting security auditing to track all interesting activities
and file accesses
- In process independent EAL4 Common Criteria evaluation (which
should complete shortly)
A security tag, or sensitivity level, range is assigned
to the user. These tags are also assigned to system objects, such
as files and directories. A user can perform an action (execute
a program or access a file or directory) only if the security label
of the object falls within the users label range. Passwords
are used for the more sensitive administration tasks (such as running
SMC), so even damage from password guessing login can be limited.
Changing roles requires passwords, even if the user is allowed into
Labels are predefined by the security administrator. They can
be hierarchical for fine-grained control of access. There are several
sample label sets provided on the label_encodings files that can
be used as-is or as a basis for a new label scheme.
There are a few fundamental differences between TS8 and S8OE:
1. CDE is the only supported desktop.
2. No remote file system mounting is allowed during installation.
3. There is no upgrade installation option, (although there will
be an upgrade option from TS8 to TS 8 4/01 release).
4. Solaris Web Start installation is not supported.
Most other aspects of Solaris 8 are supported on TS8, including
volume management and all naming services. Strangely, even NIS is
supported, even though it has a reputation for poor security.
Detailed information about TS8 is available at:
The entire documentation set is also available at: docs.sun.com.
In addition to the how to type of information, they provide
detailed security information. For instance, they explain how to use
TS8 to conform to security standards, and describe which changes would
invalidate that conformation. They include configuration and installation
checklists and a suite of planning and configuration steps that need
to be taken as part of a full TS8 deployment, which includes planning
user security, workstation hardware configurations, network planning,
auditing, and installation methodology.
TS8 is designed to stop most known attack forms. For instance,
one form of attack against a UNIX user or system involves keystroke
capture, in which a users communication (such as password)
is captured as typed. TS8 provides a trusted path feature,
which makes this impossible. Likewise, a Trojan horse program could
fool a user into disclosing his password. For example, a fake login
screen could ask for userID and password and store them away. To
solve this problem, trusted programs cause the GUI to display a
tamper-proof trusted graphic in a reserved area. Users
know it is safe to interact with a program when the graphic is displayed.
This graphic is not displayed at the login screen, but the TSOL
secure TCP/IP protocol is used so the screen cannot be spoofed.
No other X connections are allowed to this display.
Unfortunately, no operating system can provide 100% security.
For example, a spoofed email could still be sent to users with incorrect
instructions. For this, as with most other security issues, a strong,
enforced, up-to-date security policy is the best recourse. There
is flexibility, as is the case with all forms of UNIX, which can
lead to problems. A trusted host can be configured to allow access
from an untrusted host, potentially compromising security. At least
TS8 provides the tools to prevent this type of problem, however.
The trusted path concept also works across a network,
because trusted hosts talk the TSOL protocol to each other. From
an unsecure host, passwords could still be snooped, unless secure
protocols like VPN are used.
Installation is similar to standard Solaris 8, with the exception
of queries about Kerberos configuration, a DNS servers form (up
to three) and a DNS search domains form (up to six).
Once installation is complete, the system is still not quite usable.
No root login is allowed, for example, so a special install
account is available. Logging in as user install with
password install produces a pop-up window stating that
logins are disabled, and asking whether to disable them. To enable
full system availability, I elected to enable logins. Once in, a
dialog box shows last login information, the message of the day,
the last console messages, and the current label setting. The CDE
screen also shows the current security label within the trusted
graphic bar at the bottom margin.
On the whole, users still log in with user name and password.
Password management is improved though: they can be user or computer
generated, can be aged to require a change, and can also have specific
length requirements. However, they can still be dictionary words
(and thus easily cracked). At long last, the number of login failures
can be set to cause a lockout of the account.
I next assumed the root role, which is an option on
the right mouse button on the workspace window boxes. It creates
a new root workspace, which is in the root role. More workspaces
can be created as needed. I then ran the Sun Management Console
to add a user. The first invocation took a few minutes as SMC scanned
the system, but then performance was acceptable, especially in a
system with at least 256 MB of memory. After a bit of trial and
error, I created a standard user account for myself (by selecting
Trusted Solaris Management Console, Trusted Solaris
Configuration, and Users). I was asked to enable
the root role and was challenged for that roles password.
Once the user was created, I clicked on User Properties
and an extensive dialog box appeared. Here I could change normal
account parameters, set extensive password options, assign rights,
roles, trusted Solaris attributes, and auditing options to the user.
(I selected Primary Administrator.)
Logging in as the new user allowed me to select the label under
which to run that session (unclassified or classified). Once logged
in, I had the usual four workspaces and an unclassified
label display in the trusted graphic. Creating new workspaces for
classified and root work was easy (from the workspace right mouse
button menu). Executing a ps command in each window resulted
in a different view of the system. The normal user workspace only
showed processes owned by me, excluding the processes from the classified
workspace. The classified workspace ps showed both my classified
and unclassified processes. The root workspace showed only root
processes. Changing workspace labels within a workspace (from admin_low
to admin_high, for example) caused new processes in
that space to run at the new label level. For example, I could have
an admin_low and an admin_high window open
at the same time in the same workspace, with ps results showing
different views of the system.
Thus, for production environments, a first major step in deployment
is to assign appropriate labels. Labels can be disjoint, hierarchical,
or both. Hierarchical labels create supersets of access, with each
higher label having more access than the one below. Disjoint labels
(e.g., admin, engineering, accounting) provide totally separate
access and do not allow access between labels. There is additional
flexibility with the compartment and class fields, allowing more
subdivisions within labels. In essence, any type of hierarchical
or disjoint access arrangements can be created with a proper label
configuration. Users with multiple label access can change the current
workspace label via the Change Workspace Label option
on workspace right mouse button. For simplicity, most sites use
a few labels.
Consider a Web server, for example. There might be three labels:
public, private, and staging. A Web server daemon running with public
label can only see processes, files, directories, and devices in
the public label space. A nice feature is that each label space
has its own port space (this concept is patented by Sun), so public,
private, and staging could each have a port 80 with a listening
Web daemon. As another example, a user telnetting from an unsecure
system would not even see his own processes (e.g., from a trusted
login) that run at a higher label range. From an operating system
point of view, TS8 implements multiple virtual machines (one per
label), with commands to allow access between VMs. This feature
makes TS8 perfect for ISPs and others who share machines among multiple
users. A single machine could host N Web servers, each limited
to its own process, port, and file system space. Note that it would
take a lot of work to relabel a system if the labeling scheme needed
to be changed, so it is important to determine an appropriate scheme
at the outset.
User training is a key part of using TS8. If the TS8 system is
an autonomous server (such as email or Web) with no users, then
no user training is needed (given that there are no users). With
more general-purpose machines, users need to know how to secure
their objects. For the users allowed to change labels, they need
to know when it is appropriate to do so.
The estimated performance penalty for jobs running under TS8 is
very low. Host applications run about the same performance. Trusted
networking does cause a performance impact because of the use of
TSOL. The more labels in the systems involved in a network communication,
the larger the performance impact. Still, thats a small price
to pay for greatly increased security.
Even with all of the discussion above about managing a TS8 system,
there are still many features Ive left unexplored, including
network security, file and device management, and the available
Overall, the usability of Trusted Solaris 8 seemed quite good.
For most purposes, it looks like standard Solaris. There is more
work for administrators in creating accounts, managing labels and
roles, and helping users with the security features. There is quite
a learning curve to assimilate all the power that TS8 delivers to
its users. The end result, a system with greatly improved security,
is worth all the effort. Any site that has systems with sensitive
content or has users that are disjoint and should remain disjoint
should try TS8. Likewise, sites with a variety of hosts running
with varying security needs should use TS8 to manage the access
between them. TS8 is much more usable than previous secure Solaris
versions, and the price is low compared to the enhancements it can
provide to its users.
Peter Baer Galvin (http://www.petergalvin.org) is the Chief
Technologist for Corporate Technologies (http://www.cptech.com).
Before that, Peter was the systems manager for Brown Universitys
Computer Science Department. He has written articles for Byte and
other magazines, and previously wrote the Petes Wicked World
and Petes Super Systems columns at SunWorld/Unix Insider Magazine.
Peter is coauthor of Operating Systems Concepts and Applied Operating
Systems Concepts textbooks. As a consultant and trainer, Peter teaches
tutorials and gives talks on UNIX security and systems administration.
He can be reached at: firstname.lastname@example.org.