New Security Features in the Solaris 2.6 Release
Starting with the Solaris 2.6 release. the following new features are provided to enhance security.
The Pluggable Authentication Module (PAM) framework.
A noexec_user_stack variable, set in the /etc/system file, which enables you to specify whether stack mappings are executable.
Pluggable Authentication Module (PAM)
PAM enables you to plug in new authentication technologies without changing the login, ftp, or telnet commands. You can also use PAM to integrate UNIX login with other security mechanisms, such as data encryption standard (DES) or Kerberos. You can also use this framework to plug in mechanisms for account, session, and password management. See Chapter 22, “Using Authentication Services,” for more information.
Executable Stacks and Security
A number of security bugs are related to default executable stacks when permissions are set to read, write, and execute. Although the SPARC and Intel application binary interface (ABI) mandates that stacks have execute permissions, most programs can function correctly without using executable stacks.
Starting with the Solaris 2.6 release, a noexec_user_stack variable enables you to specify whether stack mappings are executable. By default, the value for the variable is 0, which provides ABI-compliant behavior. If the variable is set to non-zero, the system marks the stack of every process in the system as readable and writable but not executable.
Disabling Programs from Using Executable Stacks
Use the following steps to disable programs from using executable stacks.
1. |
Become superuser. |
2. |
Edit the /etc/system file and add the following two lines. set noexec_user_stack=1
|
3. |
Save the changes and reboot the system. |
 | When the noexec_user_stack variable is set to a non-zero value, programs that execute code on their stack are sent a SIGSEGV signal, which usually terminates the program with a core dump.When the noexec_user_stack_log variable is set to a non-zero value, core dump programs also generate a warning message, which includes the name of the program, the PID, and the UID of the user who ran the program, as shown in the following example. |
a.out[347] attempt to execute code on stack by uid 555
The message is logged by the syslogd(1M) daemon when the syslog kern facility is set to notice level. This logging is set by default in the syslog.conf(4) file, which means that the message is sent to both the console and to the /var/adm/messages file.
When you have set the noexec_user_stack variable, you can monitor these messages to observe potential security problems. You can also monitor the messages to identify valid programs that depend on executable stacks and have been prevented from correct operation.
You can explicitly mark program stacks as executable with the mprotect(2) function. See the mprotect(2) manual page for more information.
NOTE
Because of hardware limitations, executable stack problems can be caught and reported only on sun4m, sun4d, and sun4u platforms.
Disabling Executable Stack Message Logging
If you do not want to log executable stack messages, you can set the noexec_user_stack_log variable to zero in the /etc/system file. Note that even if you disable executable stack message logging, the SIGSEGV signal may continue to dump core for the executing program.
Use the following steps to disable executable stack message logging.
1. |
Become superuser. |
2. |
Add the line set noexec_user_stack_log=0 to the /etc/system file. |
3. |
Reboot the system. |