Security: Pete's Wicked World by Peter Galvin

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

SunWorld
December  1997
[Next story]
[Table of Contents]
[Search]
Sun's Site
Abstract
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)


Mail this
article to
a friend
Remember the bad ol' days of name services? If you wanted to have SunOS use DNS for hostname resolution, you had to replace a few system libraries. Before Solaris 2.6, if you wanted to have your system use an authentication method besides /etc/shadow, NIS, and NIS+, you had to replace important system binaries such as login, telnet, ftp, rlogin and rsh. Now Solaris has a feature called PAM, which does for authentication what /etc/nsswitch.conf did 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.

Advertisements

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 /etc/pam.conf file. For example:

su auth requisite /usr/lib/security/pam_inhouse.so.1  
su auth required /usr/lib/security/pam_unix.so.1 debug
telnet session required /usr/lib/security/pam_unix.so.1  
login auth required /usr/lib/security/pam_unix.so.1 debug
login auth optional /usr/lib/security/pam_inhouse.so.1  
rlogin auth sufficient /usr/lib/security/pam_rhosts_auth.so.1  
rlogin auth required /usr/lib/security/pam_unix.so.1  

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 /usr/lib/security.

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 error via 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 system.

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 sent through syslog and by default ends up in /var/adm/messages.

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 authentication. /etc/default/login has important variables that control system-wide security, such as whether to allow root logins from non-console sources.

The Bookstore
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 Buglist
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
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.

Resources

About the author
[Peter Galvin's photo] 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 peter.galvin@sunworld.com.

What did you think of this article?
-Very worth reading
-Worth reading
-Not worth reading
 -Too long
-Just right
-Too short
 -Too technical
-Just right
-Not technical enough
 
 
 
    

SunWorld
[Table of Contents]
Sun's Site 		[Search]
Feedback 		[Next story]
Sun's Site

[(c) Copyright Web Publishing Inc., and IDG Communication company]

If you have technical problems with this magazine, contact webmaster@sunworld.com

URL: http://www.sunworld.com/swol-12-1997/swol-12-security.html
Last modified: