Can 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.

The Need

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.

Features

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.

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 Sun’s 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 of information.

TS8 provides many features, including:

• 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 remote hosts
• 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 user’s 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 that role.

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:

http://www.sun.com/software/solaris/trustedsolaris

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 user’s 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.

Implementation

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 role’s 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, that’s 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 I’ve left unexplored, including network security, file and device management, and the available management tools.

Summary

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 University’s Computer Science Department. He has written articles for Byte and other magazines, and previously wrote the Pete’s Wicked World and Pete’s 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: pbg@petergalvin.org.