This chapter is from the book
This chapter is from the book
This chapter is from the book
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.
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 means that files created by system daemons are created with permission bits that are 666 (readable and writable by all users). This can be a problem because it gives normal users permission to overwrite the contents of system files.
In Solaris 8 OE, the default system umask has changed to 022 from the 000 in previous Solaris OE releases. The default value of 022 is defined by the CMASK variable in the /etc/default/init file. To define a different umask, the CMASK definition in /etc/default/init must be changed.
Use the following script 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 Services
System services are started by the init system. Some services are not necessary to system operation and should be disabled. There are also services that 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 purposes are listed here:
- /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/rcS.d single user
- /etc/rc0.d shutdown
- /etc/rc1.d start
- /etc/rc2.d multi-user
- /etc/rc3.d multi-user (default)
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 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 will discover a way to exploit the system using an enabled service.
The revision 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.
Kernel Adjustments
There are several kernel adjustments that can be made to increase Solaris OE security. The /etc/system file contains kernel-specific parameter adjustments.
CAUTION
Be careful when making changes to this file. Mistakes in this file may prevent the system from booting correctly.
NFS Server
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 only process requests from these privileged ports. If the system will act as an NFS server, add the following line to the /etc/system file to any Solaris 2.5.1 OE or later:
set nfssrv:nfs_portmon = 1
This change may prevent some NFS clients from operating correctly. There have been reported problems with older versions of Linux and SCO UNIX.
Executable 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. 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_logenabled, the system logs programmatic attempts to execute code on the stack. This 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. Nonexecutable 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 only works on the following SPARC architectures: sun4d, sun4m, and sun4u hardware.
NOTE
All 64-bit Solaris OE processes use nonexecutable stacks by default.
Core Files
Core files contain the memory image of an executing process that has been 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 can 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 have read the /etc/ shadowfile to check a password or load a protected configuration file. These pieces of information are normally hidden from users but may exist in the process core file. This information may be used to attack the system.
For security reasons, the Solaris OE will not write core files for processes with an effective ID that is different from the real ID. This means that set-user-ID and set-user-GID programs will not create core files.
If core files must be used for application debugging, clean up old ones. From time to time, search the file system for old core files and delete them. This will help prevent the file system from becoming too full.
Solaris 7 OE, 8/99 and later Solaris OE 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. The set-user-ID feature must be used with care and should be enabled only on development and testing systems. This feature can also 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.
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 the root causes of problems, and watching attackers. There are typically two types of log files in the Solaris OE: system log files typically managed by the syslog daemon, and application logs created by the application.
Log Files Managed by syslog
The syslogdaemon 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 onto 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. Uncomment the following line in /etc/syslog.conf to enable logging these messages:
# auth.notice ifdef(´LOGHOST', /var/log/authlog, @loghost)
Save the file and use the following command to force syslogd to reread its configuration file:
# kill -HUP ´cat /etc/syslog.pid´
or for Solaris 7 and 8 OE:
# pkill -HUP syslogd
All of these files should be examined regularly for errors, warnings, and signs of an attack. This task can be automated by using log analysis tools or a simple grep command.
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, but it should be created. If this file exists, the /usr/bin/login program records failed log-in attempts. All of these logs should be monitored for problems.