Solaris Operating Environment Security: Updated for Solaris 9 Operating Environment

Like this article? We recommend 

Securing File Systems and Local Access

Often, administrators are greatly concerned about attackers breaking into systems remotely. We recommend that you have equal concern for local, authorized users gaining extra privileges on a system by exploiting a problem with internal system security.

This section contains the following topics:

• "Performing an Initial Installation"
• "Minimizing the Solaris OE Installation"
• "Securing the Console"
• "Configuring the File System"
• "Managing Accounts"
• "Securing the init System"
• "Making Kernel Adjustments"
• "Managing Log Files"
• "Configuring Authentication"

Performing an Initial Installation

Sun works toward improving the Solaris OE with every release. Each new release includes additional features and improvements to enhance system security. Always use the latest version of the Solaris OE that your applications support.

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

To prevent an attacker from modifying a system or creating backdoors before you have the opportunity to secure the system, do not attach a system to a public network until security modifications are completed.

Deciding to either upgrade or re-install a system with the latest Solaris OE release is a challenging one from a security perspective. Ideally, all systems are installed from Sun media to avoid any potential of malicious modifications. However, it is not always appropriate to re-install the OE. When upgrading deployed systems, it is strongly recommended that the integrity of the Solaris OE image be verified, at a minimum, through a mechanism such as the Solaris Fingerprint Database.

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

The Solaris OE /var file system contains system log files, patch data, and files for printing, mail, and other services. The disk space required for these files varies over time. Most systems (and all servers) should maintain /var as a separate partition from the root file system.

Mail servers should maintain a large, separate /var/mail partition 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 or capture system core dumps.

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

Minimizing the Solaris OE Installation

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

For detailed instructions, recommendations, and processes to minimize the Solaris OE, refer to the Sun BluePrints OnLine article "Solaris_ Operating Environment Minimization for Security: A Simple, Reproducible, and Secure Application Installation Methodology."

Immediately after installing the Solaris OE system, apply all the patches in the Recommended and Security Patches Cluster. These patches are available from: http://sunsolve.sun.com Web and FTP sites.

Make sure that all systems have the latest Recommended and Security Patches Cluster installed.

Sun provides patches to the Solaris OE and unbundled software products when problems are corrected. You can download the recommended and security patches for the Solaris OE, even if you do not have a service contract. All other patches require a SunSpectrum^SM service contract.

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. Beginning with Solaris 8 OE, MU CDs are included in the media kit. For older Solaris OE versions, the updates are only available to service contract customers.

SunService^SM provides a variety of tools to assist in patching systems. These include the PatchDiag, PatchCheck, and PatchManager. For more information about these tools, refer to SunSolve OnLine.

Care must be taken when applying patches to a system. Some patches modify the system initialization scripts and may 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 once again. Be sure to examine all system init scripts and test all patches on non-production systems to discover any such configuration changes.

Securing the Console

There are several security mechanisms that Sun hardware systems provide for console security. 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. Also, it is possible to prevent users from using the keyboard sequence to interrupt the Solaris OE and drop to the OpenBoot PROM level.

This section contains the following topics:

• "Using OpenBoot PROM Security Modes"
• "Monitoring EEPROM Password Guessing"
• "Disabling Keyboard Abort"

Using OpenBoot PROM Security Modes

Sun's SPARC hardware provides additional console security features. These features prevent EEPROM changes, hardware command execution, and 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 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, and it should not be set as the same password. Once set, the OpenBoot PROM password is not displayed, but can be retrieved in clear text form. When changing the OpenBoot PROM password, the system does 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.

The two security modes available are command and full.

• Unless an authorized user has the correct password, 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 full security mode requires operator interaction to boot the system. It does 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 to set the security mode.

  Here is an example of setting the mode to full:

  # eeprom security-mode=full
  Changing PROM password:
  New password: password
  Retype new password: password

To Set a New EEPROM Password

• Use the following command to set a new EEPROM password.

  # eeprom security-password=
  Changing PROM password: 
  New password: password
  Retype new password: password

  Be sure to include the trailing equal sign (=).

To Make OpenBoot PROM Changes at the OpenBoot PROM Level

• To make these OpenBoot PROM changes at the OpenBoot PROM level, use the following example.

  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-password password
  security-password =

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

Monitoring EEPROM Password Guessing

If someone guesses or mistypes the OpenBoot PROM password, a time-out period of ten seconds occurs and the attempt is counted.

To See How Many Failed Login Attempts Were Made

1. Use the following command to see how many failed login attempts were made.

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

2. To add this command to an initialization script to track password attempts and reset the counter, use the following command.

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

   When the security mode is enabled, losing the OpenBoot PROM password may require you to 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 no longer boots without the new password. If this event happens, you should contact the SunService organization for assistance.

Disabling Keyboard Abort

Using the keyboard abort sequence on SPARC systems, users can drop to the OpenBoot PROM level while the Solaris OE is running. This feature can be disabled in Solaris 2.6 and newer OEs. Disabling this feature may be helpful, for example, 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.

One mechanism for disabling the keyboard abort sequence feature is to change the following line in the /etc/default/kbd file from:

#KEYBOARD_ABORT=enable

to:

KEYBOARD_ABORT=disable

When you disable the keyboard abort sequence using this mechanism, it is maintained after a system reboot.

If the system hangs or become unusable, power it off to reset it. With this feature disabled, it is no longer able to create a crash dump from the OpenBoot PROM level on a running system for analysis.

Also, you can disable the keyboard abort sequence feature by using the kdb command directly to query and change the state of the KEYBOARD_ABORT option.

Configuring the File System

You can configure the Solaris OE file system to provide additional protection. The default file permissions on some files are not adequate. Also, several mount options are available to increase security, when used effectively. The Solaris_ Volume Manager system needs some adjustment to prevent attackers from gaining superuser privileges.

This section contains the following topics:

• "Adjusting File Permissions"

• "Reviewing set-user-ID and set-group-ID Files"

• "Setting Mount Options"

• "Securing Solaris Volume Manager"

Adjusting File Permissions

Solaris OE versions prior to Solaris 9 OE ship with file system permissions that need to be adjusted for security reasons. With the release of Solaris 9 OE, this adjustment is no longer necessary for the core Solaris OE packages. In Solaris 8 OE and older versions, many files and directories have the group write bit set. In most instances, this permission is not necessary and should be switched off.

Although file permission changes are not required for Solaris 9 OE and newer releases, they may be required of applications installed on top of the OE. Consequently, monitor permissions on all Solaris OE versions.

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

http://www.sun.com/blueprints/tools

or

ftp://ftp.wins.uva.nl/pub/solaris/fix-modes.tar.gz

Please note that this tool is not supported by Sun. The fix-modes version available from sun.com is precompiled while the version from uva.nl is not. If compilation is required, it must be performed on a Solaris OE system with a C compiler. Once compiled, install the fix-modes files 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 their original state. Execute the fix-modes tool after installing any packages or patches.

Sun continues to refine file permissions and group ownerships shipped in the Solaris OE media kits. Enhancements to fix-modes are implemented and tested for specialized Sun servers such as the Sun Fire 15K system controller. Periodically download the latest version of the fix-modes software to ensure that you have the enhancements.

Reviewing 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. This file 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-ID and/or set-group-ID bit set is written correctly with security in mind, it can be a useful method for solving some tricky operational problems.

The set-user-ID and set-group-ID commands that have flaws are often used to exploit the 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 maintain an up-to-date system with the latest set of patches.

Attackers may 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 technique allows the attacker to execute the shell to gain elevated privileges (most often superuser).

To Find All set-user-ID and set-group-ID Files On a Server

• Use the following command to find all the set-user-ID and set-group-ID files on a server.

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

  Refer to the next section, "Setting Mount Options," for tips on preventing attackers from storing backdoor files or overwriting and replacing files on a file system.

  You may want to obtain and use the Solaris Fingerprint Database. This tool enables an administrator to verify, through a crytographic 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:

  http://sunsolve.sun.com

  The Sun Blueprints OnLine article "The Solaris Fingerprint Database" provides detailed examples on how to use the Fingerprint Database, descriptions of some tools to enhance its usefulness, and how a sample rootkit might be detected with the Fingerprint Database. The Sun BluePrints OnLine article is available from:

  http://www.sun.com/blueprints/0501/Fingerprint.pdf

Setting Mount Options

The Solaris OE file system partitions can be mounted with various options that enhance security. As described in the previous section, sometimes attackers use set-user-ID files to create ways to gain higher privileges. These backdoors may be hidden anywhere on a file system. While a file may have a set-user-ID bit, it is not 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 in read-only mode to prevent file modification. This configuration prevents an attacker from storing backdoor files or overwriting and replacing files on a 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. A reboot is required to change a nosuid file system to suid. Watch for unscheduled system reboots.

Different system partitions support different mount options. The /usr partition 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 newer releases of the Solaris OE. This limitation 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

Although these file system 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.

Securing Solaris Volume Manager

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

The vold daemon 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 is supported, rmmount mounts the file system.

If the system does not require the automatic mounting of CD-ROMs and diskettes, vold should be disabled. For example, a server does not need it, but a workstation may.

To disable this service, remove the Solaris Volume Manager packages SUNWvolr, SUNWvolu, and SUNWvolg.

If volume management is necessary, the mount options for some file systems should be modified for security. As previously mentioned, file systems with the suid option can be problematic. In Solaris OE versions prior to release 8, the default Solaris Volume Manager 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 diskette 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

Solaris 8 OE and newer releases have these lines in the file by default. With these options, the set-user-ID bit on executables is ignored on file systems that are mounted by the Solaris Volume Manager system.

Another security issue exists when using writable automounted media such as disks, zip diskettes, and jass disks. These media types are automatically mounted as publicly readable and writable directories and files. These media types pose a significant security risk on multiuser systems because any user on the system can read, write, and modify the contents of automouted media. Care should be taken to ensure that unauthorized users cannot access or modify sensitive information through automounted writable media. Ideally, authorized users should only use and access these media types locally on a system while no other users are permitted to log into the system over the network.

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

This section contains the following topics:

• "Managing System Accounts"

• "Restricting at, cron, and batch Command Access"

• "Implementing Role-Based Access Control (RBAC)"

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 backwards compatibility.

To Delete Accounts in /etc/passwd and /etc/shadow

• Use the userdel command to delete accounts in /etc/passwd and /etc/shadow.

  Here is an example of the userdel command.

  # userdel 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 string is sufficient. Unused accounts, which are not locked by default, should be locked with the passwd -1 option.

To Lock the uucp Account

1. Use the following command to lock the uucp account.

   # passwd -l uucp

2. 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 noshell executable is executed (as a login shell in /etc/passwd) a log entry is generated and the shell exits. Administrators can track unauthorized use of system accounts.

Restricting at, cron, and batch Command Access

The at, cron, and batch systems execute commands at a specified future time. User submission for the cron system is handled by the crontab command. 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 /etc/cron.d directory.

• The cron.deny and cron.allow files manage access to the cron system.

• The at.deny and at.allow files manage the access to the at and batch system.

The allow file is checked first to see if the account is explicitly allowed to use the system. Solaris OE versions not supporting role-based access control (RBAC) use rules to determine which accounts can access the cron and at systems. If neither the allow nor the deny file exists, then only users with the solaris.jobs.user authorization may use cron and at. By default, this authorization is granted to all users.

A 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 cron and at systems 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 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.

Implementing Role-Based Access Control (RBAC)

On Solaris 9 OE systems, role based access control (RBAC) provides an alternative to the standard UNIX_ root account privileges with a mechanism to grant users additional privileges without root equivalent privileges. Being able to provide this capability is a very important access control commonly referred to as "least privilege," which means that users get only the minimum privileges required to perform their tasks.

RBAC is implemented through grouping superuser-like capabilities into roles. You can create different roles for users requiring the ability to mount file systems, start privileged daemons, and other similar tasks. By providing this detailed level of system access, you can improve system security because fewer individuals have access to the root account and password. RBAC works through users logging into the system normally, then assuming special identities that permit them to perform additional tasks. Fundamentally, RBAC introduces the following three elements into the Solaris OE:

• Role – A special identity users can assume

• Authorization – A permission that can be assigned to a user or role granting access to tasks otherwise not permitted

• Rights Profile – A grouping of authorizations, commands, and additional rights that can be assigned to a user or role

Additional information on RBAC is available in the Solaris 9 Operating Environment System Administration Guide and in a white paper, titled "RBAC in the Solaris Operating Environment," available on

http://www.sun.com/software/whitepapers/wp-rbac

The following sections provide two simple RBAC examples and procedures for implementing the examples.

To Convert the Root Account to a Role

The first example illustrates how to convert the root account to a role. By doing this, additional controls can be implemented to control which accounts can have superuser privileges to root.

1. Log into the system as superuser.

2. Verify that the following line is in the /etc/user_attr file:

   root::::auths=solaris.*,solaris.grant;profiles=All

3. Add a line containing user accounts that should be able to have superuser privileges to root.

   For users Alice and Betty, you would add the following:

   alice::::type=normal;roles=root
   betty::::type=normal;roles=root

   Now both Alice and Betty have privileges to assume the root role after it is created in the next step.

   Because Alice and Betty are both local users on this system, it is possible to use the following commands to make this change, which is not necessary if the previous entries are added to the /etc/user_attr file:

   # usermod -R root alice
   # usermod -R root betty

4. Modify the type definition of the root role as follows:

   root::::type=role;auths=solaris.*,solaris.grant;profiles=All

   When the changes are made, only users Alice and Betty are able to have superuser access to the root account. In addition, the root account cannot log directly into the system regardless of the CONSOLE settings in /etc/default/login. If someone attempts to log directly into the system, the following is displayed after the login command:

   arciero console login: root
   Password: 
   Roles can only be assumed by authorized users
   Login incorrect
   Oct 27 20:09:14 arciero login: login account failure: Permission denied

   Compare this result with the following when authorized user Alice logs in to assume the root role.

   arciero console login: alice  
   Password: 
   Last login: Sun Oct 27 20:07:59 on console
   Sun Microsystems Inc.  SunOS 5.9    Generic May 2002
   $ su
   Password: 
   #

To Restart Daemons That Require Root Privileges

The following example shows how RBAC can solve a common administrative security issue—that of restarting a daemon which requires root privileges. For this example, Apache is used. The following steps create an executable script that can be run by anyone to successfully restart Apache.

1. At the to the end of the /etc/security/exec_attr file, add commands for restarting the Apache daemon:

   Apache:suser:cmd:::/etc/init.d/apache:uid=0
   Apache:suser:cmd:::/usr/bin/kill:uid=0
   Apache:suser:cmd:::/bin/rm:uid=0

2. At the end of the /etc/security/prof_attr file, add the following:

   Apache:::Apache Restart Profile:

3. Execute the following to create a profile shell role that will be used by authorized individuals to access a superuser account and restart the daemon:

   # roleadd -u 1050 -g staff -P Apache -d /export/home/apacher -m -s 
   /bin/pfsh apacher

   The Apache role definition sequence must be modified so that the Apache profile is listed before the default All and Basic Solaris User profiles.

4. Log in as superuser to the apacher profile and execute the profiles command to verify that the Apache profile is listed before the default All and Basic Solaris User profiles.

5. If the Apache profile is not listed before the All profile, review the modifications and make the necessary adjustments.

   The output should appear similar to the following:

   $ profiles
   Apache
   Basic Solaris User
   All

6. Edit the /etc/user_attr file to add the profile to appropriate accounts.

   In the following example, the apacher profile was added to the Betty user account:

   betty::::type=normal;roles=apacher

   At this point, the Betty user can log in as superuser to the apache profile shell and restart apache as follows:

   arciero console login: betty
   Password: 
   Sun Microsystems Inc.  SunOS 5.9    Generic May 2002
   arciero% su - apacher 
   Password: 
   $ /etc/init.d/apache restart

   NOTE

   The /etc/security/policy.conf file is another important RBAC configuration file for more customized configurations. Refer to its man page for additional information.

Securing the init System

The Solaris OE init system manages system services. Some services may not be needed or should be modified to improve the security posture of a system.

This section contains the following topics:

• "Setting the System Default Umask"
• "Disabling System Services"

Setting the System Default Umask

In Solaris OE releases prior to Solaris 8 OE, the default system file mode creation mask for the Solaris OE is 000. This default means that files created by system daemons are created with permission bits that are 666 (readable and writable by all users). This default can be a problem because it gives normal users permission to overwrite the contents of system files.

The Solaris 8 OE was the first release in which the default system umask changed to 022 from the 000 in previous Solaris OE releases. Newer OE releases carry forward the Solaris 8 OE changes. The default value of 022 is defined by the CMASK variable in the /etc/default/init and can be modified by changing the CMASK value.

For Solaris OE versions prior to Solaris 8, the following script should be used to set the system umask to a more reasonable value:

echo "umask 022" > /etc/init.d/umask.sh
chmod 744 /etc/init.d/umask.sh
chgrp sys /etc/init.d/umask.sh
for d in /etc/rc?.d; do
	 ln /etc/init.d/umask.sh $d/S00umask.sh
done

Disabling System Services

System services are started by the init system. Some services are not necessary to system operation and should be disabled. Also, some services may allow a system to be compromised due to incorrect configuration.

To disable services started by init, simply rename or delete the initialization script in the init system run level directory. The run level directories contain the scripts for starting or stopping services for the system run level. The system run level directories and their purpose as follows:

• /etc/rcS.d single user
• /etc/rc0.d shutdown
• /etc/rc1.d start
• /etc/rc2.d multi-user
• /etc/rc3.d multi-user (default)
• /etc/rc4.d multi-user (unused)
• /etc/rc5.d shutdown and power off
• /etc/rc6.d shutdown and reboot

These directories contain initialization scripts to start or stop services. Initialization scripts that begin with either an "S" or a "K" are executed by the init system. "S" scripts start services, and "K" scripts stop or "kill" services.

If you rename the scripts, make sure the name does not begin with these letters. It is recommended that an underscore (_) be placed at the beginning of the name. This practice makes it easy to enable services that may be needed later. For example:

# cd /etc/rc2.d
# mv S99dtlogin _S99dtlogin

For security purposes, only required services should be enabled. The fewer services that are enabled, the less likely it is that an attacker can discover a way to exploit the system using an enabled service.

The version of the Solaris OE and the packages installed determine what services are enabled by default. Removing unnecessary packages disables some extraneous services. The remaining services should be examined to determine their relevance to the system and the hosted application.

Making Kernel Adjustments

Several kernel adjustments can be made to increase Solaris OE security. The /etc/system file contains kernel-specific parameter adjustments.

This section contains the following topics:

• "Restricting NFS Server Requests"
• "Preventing Attempts to Execute Code on Stacks"
• "Managing Core Files"

Restricting NFS Server Requests

By default, the Solaris Network File System (NFS) server system accepts client NFS server requests from any port number. These requests should come from a privileged system port. The NFS server can be adjusted to process requests only from these privileged ports.

If a system serves as an NFS server, add the following line to the /etc/system file to any Solaris OE version 2.5.1 or newer.

set nfssrv:nfs_portmon = 1

However, this change might prevent some NFS clients from operating correctly. There are reported problems with older versions of Linux and SCO UNIX. Also, some PC-based NFS client software applications are affected by this port restriction.

Preventing Attempts to Execute Code on Stacks

Some security exploitation programs take advantage of the Solaris OE kernel executable system stack to attack the system. These attack programs attempt to overwrite parts of the program stack of a privileged program in an attempt to control it.

Methods of protecting against these attacks are as follows:

• The global /etc/system flag is available in the Solaris 2.6 OE non_exec_stack.

• In Solaris 9 OE, all system commands are linked with a map file (that is shipped in /usr/lib/ld/map.noexstk that turns off the exec flag.

• The SPARCv9 64-bit API prohibits the execute flag on stack pages.

Each of these is described in the following paragraphs.

In Solaris 2.6 OE and later, some of these exploits can be avoided by making the system stack nonexecutable. Add the following lines to the /etc/system file:

set noexec_user_stack = 1
set noexec_user_stack_log = 1

With noexec_user_stack_log enabled, the system logs programmatic attempts to execute code on the stack. This feature allows you to track unsuccessful exploit programs and the account which made the attempt. Here is an example of a log message from a recent Solaris OE exploitation program that was stopped by enabling this feature:

Nov 28 11:59:54 landreth unix: sdtcm_convert[308] attempt to execute 
code on stack by uid 38918

This buffer overflow in sdtcm_convert is corrected with a patch. However, the unpatched version of the program is somewhat resistant to the attack because the stack is not executable. Nonxecutable stacks provide some added protection against vulnerabilities for which no patch is issued.

This feature does not stop all buffer overflow exploitation programs, and it does not work on Intel x86-based or older SPARC hardware. Some overflow exploitation programs work on different principles that nonexecutable stacks cannot protect against. Always install the latest security patches. The nonexecutable stack feature works only on the following SPARC architectures: sun4d, sun4m, and sun4u hardware.

Managing Core Files

Core files contain the memory image of an executing process that was terminated upon receipt of a certain signal. These files (with the file name core) are often used to investigate program errors. There are two problems with them: core files consume disk space and may contain sensitive information.

The size of the core file is based on the amount of memory consumed by the process during execution. A core file can take up a great amount of file space. A system with a full root (/) file system may not perform as expected.

More importantly, the core file may contain privileged information that users should not be able to access. While running, the process may read the /etc/shadow file to check a password or load a protected configuration file. These pieces of information are normally hidden from users but may exist in the core file. This information may be used to attack the system.

For security reasons, the Solaris OE does not write core files for processes with an effective ID that is different from the real ID. This restriction means that set-user-ID and set-user-ID programs do not create core files.

If core files must be used for application debugging, clean up the old ones. From time to time, search the file system for old core files and delete them. This practice helps prevent the file system from becoming too full.

Solaris 7 OE (8/99) and later releases include a new system utility for managing core files. The coreadm command allows an administrator to define directories and file name patterns for core files. It allows set-user-ID programs to create core files for debugging purposes. For environments where centralized SYSLOG servers are deployed, we highly recommend that you use coreadm to configure the coreadm.conf file so that it logs all core dump attempts through SYSLOG.

The set-user-ID feature must be used with care and should be enabled only on development and testing systems. This feature can be added to older Solaris 7 OE releases with patches 106541-06 or later for SPARC and 106542-06 or later for Intel systems. All Solaris OE versions after Solaris 7 OE include it.

The following example shows a /etc/coreadm.conf file configured to store core files in /var/core, using the set-user-ID coreadm features and generating a SYSLOG message when creating a core file. Do not edit the coreadm.conf file manually. For detailed instructions, refer to the coreadm man page.

COREADM_GLOB_PATTERN=/var/core/core.%f.%p.%n.%u.%g.%t
COREADM_INIT_PATTERN=/var/core/core.%f.%p.%n.%u.%g.%t
COREADM_GLOB_ENABLED=yes
COREADM_PROC_NEABLE=yes
COREADM_GLOG_SETID_ENABLED=no
COREADM_PROC_SETID_ENABLED=no
COREADM_GLOB_LOG_ENABLED=yes

Managing Log Files

Log files are used by the system and applications to record actions, errors, warnings, and problems. They are often quite useful for investigating system quirks, discovering root causes of problems, and watching attackers. There are typically two types of log files in the Solaris OE: system log files managed by the syslog daemon and application logs created by an application.

This section contains the following topics:

• "Using and Monitoring SYSLOG Log Files"
• "Using and Monitoring Application Log Files"

Using and Monitoring SYSLOG Log Files

The syslog daemon receives log messages from several sources and directs them to the appropriate location based on the configured facility and priority. There is a programmer interface [syslog()] and a system command (logger) for creating log messages. The facility (or application type) and the priority are configured in the /etc/syslog.conf file to direct the log messages. The directed location can be a log file, a network host, specific users, or all users logged into the system.

By default, the Solaris OE defines two log files in the /etc/syslog.conf file. The /var/adm/messages log files contain a majority of the system messages. The /var/log/syslog file contains mail system messages.

A third log file is defined but commented out by default. It logs important authentication log messages to the /var/log/authlog file.

To Enable Logging Messages

1. Uncomment the following line in /etc/syslog.conf to enable logging messages:

   # auth.notice ifdef(´LOGHOST', /var/log/authlog, @loghost)

2. Save the file and use one of the following commands to force SYSLOG to re-read its configuration file.

   • For Solaris OE versions prior to 7:

     # kill -HUP ´cat /etc/syslog.pid´

   • For Solaris OE versions 7 and later:

     # pkill -HUP syslogd

3. Examine all of these files regularly for errors, warnings, and signs of an attack.

   This task can be automated by using log analysis tools or a simple grep command.

Using and Monitoring Application Log Files

Application log files are created and maintained by commands and tools without using the SYSLOG system. The Solaris OE includes several commands that maintain their own log files. The following is a list of some of the Solaris OE log files:

/var/adm/sulog	      messages from         /usr/bin/su
/var/adm/vold.log	  messages from         /usr/sbin/vold
/var/adm/wtmpx	      user information from /usr/bin/login
/var/cron/log     	  messages from         /usr/sbin/cron

The /var/adm/wtmpx file should be viewed with the last command.

The /var/adm/loginlog file does not exist in the default of the Solaris OE installation; we recommend that you create it. When this file exists, the /usr/bin/login program records failed login attempts.

Monitor all of these logs for problems.

Configuring Authentication

The following items apply to both local and remote authentication.

This section contains the following topics:

• "Displaying Access Warnings"
• "Using the Pluggable Authentication Module (PAM)"
• "Setting Console Access"

Displaying Access Warnings

The contents of the /etc/issue file are displayed on the console during login and for incoming Telnet connections. It is used to display information about the system or network. This file should contain warnings about inappropriate and unauthorized use of the system. It should warn users that their sessions and accounts may be monitored for illegal or inappropriate use. Consult your legal counsel for more information.

Here is a sample legal warning from the Solaris Security Toolkit:

This system is for the use of authorized users only. 
Individuals using this computer system without authority, or in 
excess of their authority, are subject to having all of their 
activities on this system monitored and recorded by system 
personnel. 

In the course of monitoring individuals improperly using this 
system, or in the course of system maintenance, the activities 
of authorized users may also be monitored. 

Anyone using this system expressly consents to such monitoring
and is advised that if such monitoring reveals possible 
evidence of criminal activity, system personnel may provide the 
evidence of such monitoring to law enforcement officials.

You can also use the message of the day file (/etc/motd) to display warnings.

Using the Pluggable Authentication Module (PAM)

The Pluggable Authentication Module (PAM) framework provides a modular and flexible way to replace the authentication subsystem without having to modify or recompile the installed programs that access the authentication mechanism.

All the Solaris OE authentication applications use the PAM system to authenticate users and manage accounts. Each PAM module can be implemented as a shared library object. The configuration file for the PAM system is /etc/pam.conf.

The PAM system exists to provide system programmers the ability to replace the methods used to manage accounts and users. For example, it might be desirable to limit the time periods that a group of users is allowed to be logged into a system. To implement this feature, a PAM module can be written to restrict users in this way without having to replace authentication programs.

To disable a specific login method, remove or comment out its entry in the PAM configuration file. The rlogin and rsh services use inadequate authentication for security and should be replaced with a Secure Shell protocol system.

Entries in the /etc/pam.conf for unused or insecure services should be commented out.

For Solaris 8 OE and older versions, the following example shows the lines that are removed to disable rlogin and rsh:

rlogin auth sufficient /usr/lib/security/pam_rhosts_auth.so.1
rsh auth required /usr/lib/security/pam_rhosts_auth.so.1

For Solaris 9 OE, the entries in /etc/pam.conf changed. The following example shows the lines that are removed to disable rlogin and rsh in Solaris 9 OE and newer versions:

rlogin auth requisite pam_authok_get.so.1
rlogin auth required pam_dhkeys.so.1
rlogin auth required pam_unix_auth.so.1
rsh auth required pam_unix_auth.so.1

If you disable the PAM configuration for rlogin and rsh services, also remove them from the /etc/inet/inetd.conf file. Refer to the next section for more information.

Setting Console Access

The login command is part of the authentication process to access a local Solaris OE account. It is used on all access mechanisms using /usr/bin/login, such as the console and the in.telnetd daemon, to determine if a user may be granted access to the system. By default, the root user can only log into a Solaris OE system from the console device.

The console device is defined by the following entry in the /etc/default/login file:

CONSOLE=/dev/console

When this line is commented out, the root account can log directly into the system over the network via Telnet, in addition to the console. This access is not secure and should be avoided. Do not alter the default configuration.

There are two other potential settings for CONSOLE entry in /etc/default/login.

To Permit Root Logins Only Through the ttya Serial Device

• Use the following entry in /etc/default/login file to permit root log ins only through the ttya serial device:

  CONSOLE=/dev/ttya

To Restrict Direct Root Logins Entirely

• Make the following CONSOLE entry in the /etc/default/login file to restrict direct root log ins entirely:

  CONSOLE=-

  The recommended configuration is the default—where root logins are only permitted on the console.

  NOTE

  The Secure Shell version bundled with Solaris 9 OE does not restrict access based on the CONSOLE entry in the /etc/default/login file. Regardless of the CONSOLE entry, the root user may directly log in to a Solaris 9 OE system. A root user's access to a Solaris 9 OE system is controlled through the Secure Shell configuration file.