This chapter is from the book

Initial Installation

Building a secure Solaris OE system involves installing a new system with the
latest version of the Solaris OE and applying the latest patches. Many of the
changes described in this chapter can be implemented during installation by the
Solaris™ Security Toolkit.

Solaris Security Toolkit

The goal of the Solaris Security Toolkit is to automate and simplify building
secured Solaris OE systems based on the recommendations in this chapter. The
Solaris™ Security Toolkit focuses on Solaris OE security modifications to
harden and minimize a system. Hardening is the modification of Solaris OE
configurations to improve the security of a system. Minimization is the removal
of unnecessary Solaris OE packages from the system, which reduces the number of
components that have to be patched and made secure. Reducing the number of
components can reduce entry points to an intruder.

NOTE

Configuration modifications for performance enhancements and software
configuration are not addressed by the Solaris Security Toolkit.

The Solaris Security Toolkit is designed to harden systems during
installationthis objective is achieved by using the JumpStart™
technology as a mechanism for running the Solaris Security Toolkit scripts.
Additionally, the Solaris Security Toolkit can be run outside the JumpStart
software framework in a standalone mode. This standalone mode allows the Solaris
Security Toolkit to be used on systems that require security modifications or
updates yet cannot be taken out of service to reinstall the OS from scratch.

The Solaris Security Toolkit is available on the CD-ROM accompanying this
book and from:

Each new release includes security improvements and additional features to
enhance system security. Always use the latest version of the Solaris OE that
your applications support. This chapter is written to Solaris 8 OE (01/01).

To prevent an attacker from modifying a system or creating backdoors before
you have the opportunity to secure it, perform an initial Solaris OE install. Do
not perform an upgrade to an existing Solaris OE system. Also, install the
system from an original Sun Solaris OE CD-ROM, and do not attach the system to a
"public" network until the security modifications are made.

Partitions

When creating operating system file partitions, be sure to allocate adequate
disk space for system directories, log files, and applications. Certain server
applications or services may require extra disk space or separate partitions to
operate effectively without impacting other services. Typically, at a minimum
have partitions for the root file system (/) and /var.

The Solaris OE /var file system contains system log files, patch data, print,
mail, and files for other services. The disk space required for these files
varies over time. We recommend that most systems (and all servers) maintain /var
as a separate partition from the root file system. For mail servers, maintain a
large, separate /var/mailpartition to contain user mail files. These extra
partitions help prevent a full /var or /var/mail file system from affecting the
operation of the system. Provide extra space in /var if you intend to store
large log files.

Additional partitions, such as /usr and /opt, may be required if you follow
the recommendations made in the "Mount Options" on page 11.

Minimization

It is important to reduce the Solaris OE installation down to the minimum
number of packages necessary to support the application to be hosted. This
reduction in services, libraries, and applications helps increase security by
reducing the number of subsystems that must be disabled, patched, and
maintained.

Please refer to Chapter 3, which describes a methodology for the minimization
and automation of Solaris OE installations.

Patches

Sun provides patches to the Solaris OE and unbundled software products when
problems are corrected. Anyone can download the recommended, security, and Y2K
patches for the Solaris OE. All other patches require a SunSpectrumSM
service contract. All systems should have the latest recommended,
security, and Y2K patches installed. Subscribe to the Sun security bulletin
mailing list to receive notification of important security related patches.
Recently, Sun started providing Maintenance Updates (MU) for the Solaris OE. An
MU is a tested combination of patches for a specific release of the Solaris OE
that installs in one quick and easy step. These updates are only available to
service contract customers.

SunSpectrum service contract customers have access to all patches,
maintenance updates, and the patchdiag tool. The patchdiag tool takes a list of
current patches available from Sun and examines the local system to determine
patches that have not been applied. It checks for new versions of patches that
have been applied. The patchdiag tool should be run on systems at least once a
week to determine if important patches need to be applied such as security
patches.

Immediately after a Solaris OE system is installed, all recommended,
security, and Y2K patches should be applied. These patches are available from
the http://sunsolve.sun.com
web and FTP sites.

Care must be taken when applying patches to a system. Some patches modify the
system initialization scripts and can disable security changes made to a system.
Scripts that were deleted from the init run level directories to disable
services could be replaced during the patch installation process, enabling the
service again. Be sure to examine all system init scripts and test all patches
on nonproduction systems to discover any such configuration changes.

Console Security

Sun hardware systems provide several security mechanisms. The OpenBoot™
PROM system on SPARC systems has two security modes, command and full. Failed
login attempts to the OpenBoot PROM system can be monitored. It is possible to
prevent users from using the keyboard sequence to interrupt the Solaris OE and
drop to the OpenBoot PROM level.

OpenBoot PROM Security Modes

Sun's SPARC-based hardware provides some additional console security
features. These features prevent EEPROM changes, hardware command execution, and
even system start-up without the appropriate password. This password protection
only works while the system is at the OpenBoot PROM level (Solaris OE is
stopped). Similar features might be available on Intel x86-based hardware;
however, they are not supported in the Solaris OE (Intel platform edition).

The OpenBoot PROM password is not related to the Solaris OE root password.
Once set, the OpenBoot PROM password is not displayed, but can be retrieved in
clear text form. You should not set the OpenBoot PROM password to the same
password as the root password. When changing the OpenBoot PROM password, the
system will not ask for the old password prior to changing it to the new one. In
some environments it may make more sense to set the OpenBoot PROM password to
something known to the hardware technicians.

There are two security modes available. The command security mode prevents
EEPROM changes and hardware command execution while at the OpenBoot PROM level.
The full security mode provides the features of the command mode and, in
addition, does not allow the system to boot without the correct OpenBoot PROM
password. The fullsecurity mode requires operator interaction to boot the
system. It will not boot without a password. Do not use this feature on servers
or other systems that must boot quickly without manual intervention.

To set the security mode, use the eeprom command in the Solaris OE. Here is
an example of setting the mode to full:

The system EEPROM security mode can be disabled by setting the security mode
to none.

Monitoring EEPROM Password Guessing

If someone enters an incorrect OpenBoot PROM password, a time-out period of
ten seconds occurs and the attempt is counted. To see how many bad login
attempts have been made, use the following command:

# eeprom security-#badlogins
security-#badlogins=3

You may want to add this command to an initialization script to track
password attempts. To reset the counter, use the following:

# eeprom security-#badlogins=0
security-#badlogins=0

Losing the OpenBoot PROM password requires that you replace the EEPROM. An
attacker with superuser access could set the security mode to full, set the
password to random characters, and reboot the system. The system will no longer
boot without the new password. If this happens, you must contact the
SunServiceSM organization for a new EEPROM.

Disabling Keyboard Abort

SPARC based systems can drop to the OpenBoot PROM level while the Solaris OE
is running, using the keyboard abort sequence. The keyboard abort can be
disabled in Solaris 2.6 and newer OEs. This feature may be useful in
uncontrolled lab environments to prevent users from bringing systems down. If
OpenBoot PROM security mode full or command is enabled, the EEPROM settings
cannot be altered without a password.

To disable the keyboard abort sequence change the following line in the
/etc/default/kbd file:

#KEYBOARD_ABORT=enable

to:

KEYBOARD_ABORT=disable

Should the system hang or otherwise become unusable, it will have to be
powered off to be reset. It will no longer be possible to create a crash dump
from the OpenBoot PROM level on a running system for analysis.

File System

The Solaris OE file system can be configured to provide added protection. The
default file permissions on some files are not adequate. There are also several
mount options that increase security when used effectively. The Solaris™
Volume Manager system needs some adjustment to prevent attackers from gaining
superuser privileges.

Adjusting File Permissions

The Solaris OE ships with some file system permissions that should be
adjusted for security reasons. Many files and directories have the group write
bit set. In most instances, this permission is not necessary and should be
switched off.

Casper Dik has created a tool to adjust these permissions. The tool is called
fix-modes and can be downloaded from:

Please note that this tool is not supported by Sun. The fix-modesprogram must
be compiled on a Solaris OE system with a C compiler. Once compiled, install the
fix-modesfiles and execute it to correct file system permissions. This tool has
been used in production environments for several years with no reported
problems. Be careful when installing patches and new packages. These may set
permissions back to the original default state. The fix-modes should be executed
after all packages are installed and all patches are applied.

Sun continues to refine file permissions and group ownerships with each new
Solaris OE release.

set-user-ID and set-group-ID Files

The set-user-ID and set-group-ID bits (sometimes referred to as SUID and SGID
bits) on an executable file indicate to the system that the executable should
operate with the privileges of the file's owner or group. In other words,
the effective user ID of the running program becomes that of the
executable's owner, in the set-user-ID instance. A set-group-ID file sets
the running program's effective group ID to the executable's group. If
the file is owned by root, an executable started by a normal user would operate
with superuser privileges. This is useful in allowing users to run some commands
that gather system information or write to files not owned by the user. If the
command with the set-user-IDand/or set-group-ID bit set is written correctly
with security in mind, this can be a useful method in solving some tricky
operational problems.

The set-user-ID and set-group-ID commands, which have flaws, are often used
to exploit a system. The attacker uses the elevated privileges provided by the
set-user-ID or set-group-ID mechanism to execute code on the program stack (a
"buffer overflow" attack) or to overwrite system files. When these
security problems are reported, Sun fixes them and provides a patch. This is
another reason to keep a system up to date with the latest set of patches.

Attackers may also use the set-user-ID or set-group-ID feature to create
"backdoors" into systems. One way this is done is by copying a system
shell to a "hidden" location and adding the set-user-ID bit. This
practice allows the attacker to execute the shell to gain elevated privileges
(most often superuser).

To find all the set-user-IDand set-group-IDfiles on a server, use the
following find command:

# find / -type f \( -perm -u+s -o -perm -g+s \) -ls

Store the output to a file on another system. Compare it against the current
file system from time to time and after applying patches to find any unwanted
additions.

Sun has released the Solaris™ Fingerprint Database. This tool enables
an administrator to verify, through a cryptographic checksum, the integrity of
files distributed with the Solaris OE. While useful for checking set-user-ID and
set-group-ID permission, the real benefit of the Solaris Fingerprint Database is
the detection of trojaned or maliciously modified executables. The Solaris
Fingerprint Database does not require a service contract to access and is
available from:

Mount Options

The Solaris OE file system partitions can be mounted with various options
that enhance security. As shown in the previous section, set-user-IDfiles can be
used by attackers to create ways to gain higher privileges. These backdoors may
be hidden anywhere on the file system. While a file may have a set-user-ID bit,
it will not be effective on file systems mounted with the nosuid option. The
system ignores the set-user-ID bit for all files on a nosuid mounted file
system, and programs execute with normal privilege. It is possible to mount a
file system as in read-only mode to prevent file modification. This will prevent
an attacker from storing backdoor files or overwriting and replacing files on
the file system.

Whenever possible, file systems should be mounted in read-only mode, and
should be mounted to ignore the set-user-ID bit on files.

Note that these options are not complete solutions. A read-only file system
can be remounted in read-write mode. The nosuid option can be removed. Not all
file systems can be mounted in read-only mode or with nosuid. If a file system
is remounted in read-write mode, it must be rebooted to switch back to read-only
mode. Also, a reboot is required to change a nosuid file system to suid. Watch
for unscheduled system reboots.

The system partitions support some of these mount options. The /usrpartition
can be mounted read-only. It should not be mounted nosuid because there are some
commands in this partition that have the set-user-ID bit set. The /var partition
cannot be set to read-only but can be set to nosuid. Mount all other partitions
read-only and with nosuid, whenever possible.

Contrary to suggestions in other Solaris OE security documents, it is not
possible to mount the root file system (/) with the nosuid option on modern
releases of the Solaris OE. This restriction is because the root file system is
mounted read-only when the system boots and is later remounted read-write. When
the remount occurs, the nosuid option is ignored.

Here is a partial /etc/vfstab file containing the appropriate file system
options:

While this file system's options significantly improve the security of a
system, they may cause difficulty with some third-party applications. Thoroughly
test these options before deploying them to a production system.

Volume Management

The Solaris Volume Manager system provides users an easy way to mount
removable media without requiring superuser access. CD-ROMs and floppy disks are
mounted and unmounted automatically by the volume management system. The daemon
that manages this system is called vold.

The vold uses the rmmount command to mount the removable media device. It uses
a configuration file (/etc/rmmount.conf) to determine the actions necessary
based on the device to be mounted. The vold daemon calls rmmount, which
determines what type of file system, if any, is on the media. If a file system
is present and it is supported, rmmount mounts the file system.

If the system does not require automatic mounting of CD-ROMs and floppy
disks, volume management should be disabled. For example, a server does not need
it, but a workstation may. Disabling this service can be accomplished by
removing the volume management packages (SUNWvolr, SUNWvolu, and SUNWvolg).

If volume management is necessary, the mount options for some file systems
should be modified for security. As discussed previously, file systems with the
suidoption can be problematic. In Solaris OE versions prior release 8, the
default volume management configuration is to allow suid file systems for all
removable media that are capable of supporting it. In Solaris 7 OE and previous
releases, anyone can insert a UFS-formatted floppy containing a set-user-ID
executable and gain control of the system. To prevent this situation, add the
following lines to the end of the /etc/rmmount.conf file in all Solaris OE
versions prior to 8:

mount hsfs -o nosuid
mount ufs -o nosuid

In Solaris 8 OE, these entries are set by default. With these options, the
set-user-ID bit on executables is ignored on file systems that are mounted by
the volume management system.

Accounts

Managing user and system accounts is an important aspect of Solaris OE
security. Some system accounts may need to be modified or deleted. The
time-based command execution system tools, cron and at, may need to be
configured to restrict user access.

Managing System Accounts

A default Solaris OE installation contains several accounts that either need
to be deleted or modified to strengthen security. Some accounts are not
necessary for normal system operation. These accounts include smtp, nuucp, and
listen. Some of these accounts exist to support software subsystems that are not
used or are for backward compatibility. Use the passmgmt command to delete
accounts in /etc/ passwd and /etc/shadow. Here is an example:

# passmgmt -d smtp

This command removes the /etc/passwd and /etc/shadow entries for smtp.

The remaining system accounts (except the root account) should be modified
for added security. System accounts listed in /etc/passwd have no shell listed.
Those accounts have an NP string (meaning "no password") listed in the
/etc/shadow file. By default, this is sufficient. However, some additional steps
can be taken to add more security. Use the -l option of the passwd command to
lock accounts. To lock the uucp account use the following command:

# passwd -l uucp

Also, use the -e option to the passwd command or edit the /etc/passwd file
manually to change the default shell for those accounts to /usr/bin/true. For
example:

# passwd -e uucp
Old shell: /sbin/sh
New shell: /usr/bin/true

Administrators should monitor these system accounts for abuse. The Solaris
Security Toolkit includes a shell replacement called noshell. When the
noshellexecutable is executed (as a log-in shell in /etc/passwd), a log entry is
generated and the shell exits. This allows administrators to track unauthorized
use of system accounts.

at, cron, and batch Security

The at, cron, and batch systems execute commands at a specified future time.
User submission for the cronsystem is handled by the crontabcommand. The at and
batch commands are used to submit jobs to the at system.

Access to these commands can be restricted. The access control files are
stored in the /usr/lib/crondirectory. The cron.denyandcron.allowfiles manage
access to the cronsystem. The at.denyand at.allowfiles manage the access to the
atand batchsystem. The allow file is checked first to see if the account
is explicitly allowed to use the system. If the file does not exist or the
account is not listed in this file, the deny file is checked. If the
account is explicitly listed in the deny file, then access is refused;
otherwise, access is permitted. If neither the deny nor the allow
files exist, then only the root account can use the at or cron system. The
Solaris OE includes cron.deny and at.deny files containing some system accounts.

With the release of Solaris 8 OE, access to the cron and at commands can be
controlled through the Role Based Access Control (RBAC) authorization,
solaris.jobs.user. Another benefit of the RBAC authorization framework, over
configuring cron and at configuration files locally, is its support of name
services. By centrally storing RBAC authorizations in a name service such as
NIS+, server-specific modifications can be avoided. Refer to the RBAC man pages
for additional information on authorizations.

The cronand atsystems can be problematic because commands are executed in the
future. An attacker can use these systems to implement a "logic bomb"
or other type of programmed attack that begins at some point in the future.
Without examining every at, batch, and cron submission, tracking usage and abuse
can be difficult.

Access should be restricted to the at, batch, and cron systems to prevent
attacks and abuse. By default, the Solaris OE includes scheduled cron events for
the lp, adm, and root accounts. These should not be included in the deny
files. Any additional system or software-specific accounts that do not
require cron, batch, or at access should be added to the deny files.

You may also want to restrict normal user access to these commands as well.
Individual user accounts should be listed in the deny files. To restrict
all user account access, create an empty allow file. Add only the
accounts that need access to the allow file.