Solaris 2.6 looks to cure the ol' security blues
If you care about security, you should know what's new in the latest version of Sun's OS
It's an unfortunate side effect of being in the security business. Thinking about the near-hopeless state of security in the computer industry can get you, in the words of Miles Davis, "Kind of Blue". Well, Solaris 2.6 contains some good news. It comes in two forms: the flexible pluggable authentication module (PAM) and enhanced security for process stacks. In this month's column, we examine the new security features of Solaris 2.6.
Also this month, The Buglist has news and links on Intel's global system crashing problem and CGI trouble with the "glimpse" package. And find out about Peter's new book in The Bookstore. As always, you can see The Solaris Security FAQ for all your Solaris security information needs. (1,500 words)
/etc/shadow, NIS, and NIS+, you had to replace important system binaries such as
login, telnet, ftp, rloginand
rsh. Now Solaris has a feature called PAM, which does for authentication what
/etc/nsswitch.confdid for name resolution.
Solaris PAM is based on the OSF RFC 86.0 (see Resources below). As such, it is a de jure standard. It has been implemented in Linux and should be available in other operating systems (apparently it makes so much sense that Unix vendors are implementing it instead of arguing about it). PAM modules are available for Unix, DCE, Kerberos and S/Key authentication integration. Smart card support should be available soon.
What PAM can do for you
PAM can handle four aspects of name security: authentication, account validation, session management, and password management. Authentication, as you might expect, allows arbitrary authentication methods, such as kerberos, to be invoked. Account validation checks for account and password expiration and it can access time limitations. Session management tracks usage and timing of an access. Finally, password management allows users to change their authentication information based on the invoked authentication method. For instance, if the system is using Unix passwords this module manages Unix password changes.
On Solaris 2.6, PAM is configured via the
The first column is the service name, followed by the module type, control
flag, module path, and options. When a given service is invoked on the
system, the associated module in
pam.conf is executed. To avoid security problems based on unauthorized
pam.conf modification, the
module names are either absolute paths or are relative to
The PAM facility increases its power, flexibility, and utility by allowing stacking of modules. If there are duplicate module types in the configuration file, the associated modules are invoked in order from top to bottom. The control flag dictates how the modules interrelate. The parsing of these flags is complex, but is well documented in the manual pages. Essentially, if all "requisite" and "required" modules succeed, PAM returns success. If any of them fail, an error is returned. However, if a "sufficient" is encountered and succeeds, the remaining "requisite" and "required" modules are ignored. Additionally, "requisite" means that if the module returns an error, all other modules of that type are ignored and an error is returned.
In the above example, an
su is authenticated via an in-house
mechanism and by the standard Unix method. If the in-house fails, the
request is denied and the Unix method is not even invoked. For
login, Unix must authenticate the request, but if that
succeeds the in-house method can fail and the user is still logged-in
(because in-house is optional). Finally,
rlogin is allowed if
the rhosts_auth module returns success, in which case the Unix
module is not invoked. If rhosts_auth fails, however, then Unix
must succeed or the
rlogin request is denied.
The RFC defines these flags as follows:
Note that the specification does not include "requisite." Sun says it expects this flag to be included in future versions of the spec.
An important aspect of the PAM facility is that it fails "closed." That is,
if a module fails to execute or has invalid options, PAM logs a critical
syslog. If no valid entry is found for a given
module type, the requested access is denied. Of course, this means that you
must take care when modifying
pam.conf, because improper
modifications without testing could leave all users locked out of the
What PAM doesn't do
Of course, PAM has its limitations. For instance, it does little about access control once access is granted. However, it is complementary to the GSS-API specification, which provides programs with a generic set of functions to access security features. Also, it does not solve long-standing issues such as the sending of clear-text passwords over networks. It is not a single-sign-on solution. Finally, if multiple authentication methods are stacked, users may be inclined to use the same password for each of them. This would defeat the purpose of stacked authentication.
Executable stacks and security
If you watch security bug reports, you'll notice that most of them involve overflowing the buffer on a process to escape from its limitations. For instance, setuid-programs try to provide specific functionality while not allowing a user full root access. If you escape from its programmed limits, you have full root access. These bugs are possible due to processes having execute access to their stacks. Unfortunately, the SPARC and Intel ABIs (application binary interfaces) require that stacks have those permissions. However, most programs function correctly even without stack execute permission.
A new system variable,
noexec_user_stack, allows you to specify whether
stacks are executable. It is set in
/etc/system just like
other system variables. At boot time, it is set to zero. Setting it to one
results in non-executable stacks. An attempt to execute code on the stack
will then cause a SIGSEGV signal and a warning message or a code dump,
depending on whether the process traps that signal. The warning message is
syslog and by default ends up in
Another system variable,
noexec_user_stack_log can be set to zero
to disable logging, but the signal may continue to cause the executing
program to core dump.
There is also a system call,
mprotect(2), that can be used within
a program to explicitly mark its stack as executable.
Unfortunately, the stack protection is only available on modern Sun
hardware, including the sun4m, sun4d and sun4u platforms. Note that the
system needs to be rebooted after setting variables in
/etc/system for the changes to take effect.
Of course, Solaris 2.6 has all of the security features of the previous
Solaris releases. These include system security, network security, and
/etc/default/login has important variables
that control system-wide security, such as whether to allow root logins
from non-console sources.
Shameless plug alert! The fifth edition of Operating Systems Concepts (the "dinosaur book"), the textbook that I co-write with Abraham Silberschatz, is now hitting the shelves. It includes a chapter on security. New in it are chapters on I/O, Linux, and NT.
The Intel Pentium (not "Pro" or "II") has a global problem. There's a code fragment that will crash the system, regardless of what operating system it's running. If you have a Solaris x86 system that is crashing, you'll need to watch for someone running the crash code. Details can be found at Intel
More CGI-script trouble has been uncovered. The "glimpse" package has some associated CGI scripts that can allow a Web server to be broken. This is reported in CERT VP 97.13. CERT has released a general alert because many CGI-script writers are being sloppy in handling input and are allowing callers to break out of their scripts. See CERT CA 97.25. There is also a bug in the well-used count_cgi script, reported in CERT CA 97.24.
In October, Sun released four security alerts:
155 28-Oct-1997 nis_cachemgr 156 28-Oct-1997 ftpd/rlogind 157 28-Oct-1997 sysdef 158 28-Oct-1997 rlogin
These four alerts identify security holes in the associated facilities and provide information on patches to solve the problems. Get 'em while they're hot.
Also of note: Sun has released jumbo patches for Solstice Firewall-1 V 3.
Next month's column will feature a report on the happenings at the Network Security '97 and LISA '97 conferences. As you may recall, I had intended to write about these shows in December, but this Solaris stuff got in the way.
About the author
Peter Galvin is chief technologist for Corporate Technologies, Inc., a systems integrator and VAR. He is also adjunct system planner for the Computer Science Department at Brown University, a member of the board of directors of the Sun User Group, and has been program chair for the past four SUG/SunWorld conferences. As a consultant and trainer, he has given talks and tutorials world-wide on the topics of system administration and security. He has written articles for Byte and Advanced Systems (SunWorld) magazines, and the Superuser newsletter. Peter is coauthor of the best-selling Operating Systems Concepts textbook. Reach Peter at email@example.com.
If you have technical problems with this magazine, contact firstname.lastname@example.org