This chapter is from the book
This chapter is from the book
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:
http://www.sun.com/blueprints/tools
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:
# eeprom security-mode=full Changing PROM password: New password:passwordRetype new password:password
To set a new EEPROM password, use the following command:
# eeprom security-password= Changing PROM password: New password:passwordRetype new password:password
Be sure to include the trailing equal sign ("=").
These OpenBoot PROM changes can be made while at the OpenBoot PROM level. Here is an example of setting the OpenBoot PROM security mode and password while at OpenBoot PROM level:
ok setenv security-mode command security-mode = command ok setenv security-passwordpasswordsecurity-password =
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:
ftp://ftp.wins.uva.nl/pub/solaris/fix-modes.tar.gz
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:
/dev/dsk/c0t3d0s0 /dev/rdsk/c0t3d0s0 / ufs 1 no - dev/dsk/c0t3d0s4 /dev/rdsk/c0t3d0s4 /usr ufs 1 no ro dev/dsk/c0t3d0s5 /dev/rdsk/c0t3d0s5 /var ufs 1 no nosuid dev/dsk/c0t3d0s6 /dev/rdsk/c0t3d0s6 /opt ufs 2 yes nosuid,ro
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.denyand cron.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.