Home > Articles > Operating Systems, Server > Solaris

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.


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.


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.


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.


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: password
Retype new password: password

To set a new EEPROM password, use the following command:

# eeprom security-password=
Changing PROM password:
New password: password
Retype 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-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 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

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

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:




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:

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


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.

InformIT Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from InformIT and its family of brands. I can unsubscribe at any time.


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information

To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.


Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites, develop new products and services, conduct educational research and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.


If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@informit.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information

Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.


Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.


This site is not directed to children under the age of 13.


Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information

If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.


Users can always make an informed choice as to whether they should proceed with certain services offered by InformIT. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.informit.com/u.aspx.

Sale of Personal Information

Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents

California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure

Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.


This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact

Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice

We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020