Softpanorama (slightly skeptical) Open Source Software Educational Society

May the source be with you, but remember the KISS principle ;-) Softpanorama Search

Solaris Minimization

Contents

• SecurityDocs Foundation for Minimal Solaris 10 Systems
• SolarisTM Operating Environment Minimization for Security: A Simple, Reproducible and Secure Application Installation Methodology
• Solaris Security and Minimalization A meta-analysis of which Solaris Packages to remove in order to increase security

Old News

See also Softpanorama Unix Audit and internal Scanning Tools (Internal Vulnerability Scanning) See also History of  Hardening Scripts for older generic hardening scripts (Cops, Tiger, etc.)

[Oct 19, 2004]  SecurityDocs Foundation for Minimal Solaris 10 Systems  by Glenn M. Brunette, Jr.

The topic for this article is the Solaris 10 Reduced Networking Software Group (also commonly known as the Solaris 10 Reduced Networking Meta Cluster). This software group is new and joins the five existing software groups available in Solaris today: Core, End User, Developer, Entire and Entire + OEM software groups. The Reduced Networking Software Group is positioned as a subset of Core and represents the smallest amount of Solaris that can or should be installed and have a working and supported system. (Note that for support reasons, it is not advised to remove packages installed by the Reduced Networking Software Group.)

To install the Reduced Networking Software Group, simply select it from the list when doing a graphical installation. If you are using JumpStart, then you should use the cluster keyword with the new value SUNWCrnet. The following is a sample JumpStart profile that uses the Reduced Networking Software Group. This profile was also used to build the system used as an example in this article.

***** Alex Noordergraaf and Keith Watson SolarisTM Operating Environment Minimization for Security: A Simple, Reproducible and Secure Application Installation Methodology   December 1999. This is a very good paper. It explains how to remove unnecessary packages -- actually they consider a very practical case of Solaris + Netscape Enterprise Server.  The paper a little bit weak on the tool side,  though.

The Solaris Operating Environment installation process requires the selection of one of four installation clusters:

• Core
• End User
• Developer
• Entire Distribution

Each installation cluster represents a specific group of packages (operating system modules) to be installed. This grouping together of packages into large clusters is done to simplify the installation of the OS for the mass market. Because each of these installation clusters contains support for a variety of hardware platforms (Solaris^TM Operating Environment (Intel Platform Edition), microSPARC^TM, UltraSPARC^TM, UltraSPARC II, and so on) and software requirements (NIS, NIS+, DNS, OpenWindows^TM, Common Desktop Environment (CDE), Development, CAD, and more), far more packages are installed than will actually ever be used on a single Solaris Operating Enironment.

The Core cluster installs the smallest Solaris Operating Environment image. Only packages that may be required for any SPARC^TM or Solaris Operating Environment (Intel Platform Edition) system are installed. The End User cluster builds on the Core cluster by also installing the window managers included with the Solaris Operating Environment (OpenWindows and CDE). The Developer and Entire Distribution clusters include additional libraries, header files, and software packages that may be needed on systems used as compile and development servers.

The size of the clusters varies significantly: the Core cluster contains only 39 packages and uses 52MBytes; the End User cluster has 142 packages and uses 242 MBytes; the Developer cluster has 235 packages and consumes 493 MBytes of disk space. Experience to date has shown that in many cases, a secure server may require only 10 Solaris Operating Environment packages and use as few as 36MBytes of disk space.

Installing unnecessary services, packages, and applications can severely compromise system security. One well known example of this is the rpc.cmsd daemon, which is unnecessary on many data center systems. This daemon is installed and started by default when the End User, Developer, or Entire Distribution cluster is chosen during the installation process.

There have been many bugs filed against the rpc.cmsd subsystem of OpenWindows/CDE in the last few years, and at least two CERT advisories (CA-99-08, CA-96.09). To make matters even worse, scanners for rpc.cmsd are included in the most common Internet scanning tools available on the Internet. The best protection against rpc.cmsd vulnerabilities is to not install the daemon at all, and avoid having to insure it is not accidentally enabled.

The problem described above is well known in the computer industry, and there are hundreds of similar examples. Not surprisingly, almost every security reference book ever written discusses the need to perform "minimal OS installations" [Garfinkel]. Unfortunately, this is easier said than done. Other than the occasional firewall, no software applications are shipped with lists of their package requirements, and there's no easy way of determining this information other then through trial and error.

Because it is so difficult to determine the minimal set of necessary packages, system administrators commonly just install the Entire Distribution cluster. While this may be the easiest to do from the short-term perspective of getting a system up and running, it makes it nearly impossible to secure the system. Unfortunately, this practice is all too common, and is even done by so-called experts brought in to provide infrastructure support, web services, or application support. (If your organization is outsourcing such activities, be sure to require the supplier to provide information on what their OS installation policies and procedures are, or you may be in for some unpleasant surprises.)

The rest of this article presents one method for determining the minimal set of packages required by a particular application--the iPlanet^TM Enterprise Server. Future articles will discuss other applications. The tentative list includes NFS^TM Servers (with SecureRPC and Solstice DiskSuite^TM), iPlanet^TM WebTop, and Sun^TM Cluster. If you have followed this procedure and developed the scripts for a particular application, please forward them to the authors for inclusion in future articles.

Solaris Security and Minimalization A meta-analysis of which Solaris Packages to remove in order to increase security