Ingres PAM Integration Project

From Ingres Community Wiki

The Ingres community (Ronald Jeninga of independIT Integrative Technologies GmbH) has contributed source code changes to make Ingres running on various flavors of UNIX/LINUX platforms PAM aware. PAM stands for Pluggable Authentication Modules. This PAM Framework was invented by Sun Microsystems. PAM provides applications great flexibility to use different security services without re-compilation of the application itself. That is, it provides a single API for the application. A system administrator can then reconfigure PAM to access shadow passwords or any of various supported security mechanisms without having to change or recompile the application.

Each of the UNIX/LINUX vendors has their own implementation/configuration of PAM in their OS, but the APIs are standard. PAM provides two sets of interfaces:

1. Applications Programming Interface (API) functions such as pam_start(), pam_authenticate(), pam_acct_mgmt(), pam_end(), and others.
2. Service Provider Interface (SPI) functions for PAM module writers.

The PAM modules to provide security service for PAM aware applications are located under /lib/security. The PAM configuration file is called /etc/pam.conf on Solaris/HP-UX. For Linux, the PAM control file is located under /etc/pam.d.

This documentation details recommendation to integrate the source code changes submitted by the community to the Ingres source library with the following 2 research topics in mind.

1. Review and endorse/submit the code for PAM version of ingvalidpw to the Ingres source library.
2. More comprehensive support that plugs into the Ingres GCS ( General Communications Security ) architecture.

Contents 1 Review of Ingres Community Code Changes for PAM Integration 2 Proposal for PAM Integration 3 Integration with Ingres GCS facility 4 Additional References 5 Conclusion

Review of Ingres Community Code Changes for PAM Integration

In the current Ingres security architecture, user authentication in Ingres is implemented in a separate SETUID program called ingvalidpw which directly invokes OS provided APIs for reading info from the /etc/passwd file on the standard UNIX systems or from /etc/shadow file on the UNIX systems that provide shadow passwords for additional security. Also, the source for ingvalidpw executable is being distributed in all Ingres releases under $II_SYSTEM/ingres/files/iipwd.

The source code changes from the community to support PAM in Ingres were implemented in ingvalidpw.c and mkvalidpw (utility builds ingvalidpw executable). This Media:ingvalidpw_pam.tar.gz is attached to the Ingres PAM Wiki Page. These code changes have been tested on Linux (Redhat, SuSE), Solaris, and HP-UX. Windows and TRU64 don't seem to have PAM support. VMS does support PAM but no testing has been done on VMS.

On UNIX/LINUX systems with no shadow passwords support (passwords stored in /etc/passwd), PAM doesn't require SETUID (root) permissions on 'ingvalidpw' to verify the identity of the user accessing Ingres.

On UNIX/LINUX systems with shadow passwords support, ‘setgid-shadow’ permissions on 'ingvalidpw' is just enough to successfully complete the PAM authentication. For example, in SuSE linux, by default, the shadow password file's group permission is set to shadow and group name called 'shadow' has been defined in /etc/group.

-rw-r----- 1 root shadow 653 2008-01-23 02:42 /etc/shadow

The pam_authenticate() API call will not fail if the PAM aware application is set to 'setgid - shadow' which seems to work well on Linux (red hat), HP-UX, and Solaris.

The source code changes do not contain any proprietary code. It is not required to force it to have SETUID-root for PAM authentication as done in the community implementation. (Please see “Proposal for PAM Integration” section below ).

The PAM support implemented by Ingres community uses standard Unix PAM modules (example pam_unix.so) shipped with OS, i.e UNIX passwords authentication. Thus with this implementation, the appdata_ptr member of pam_conv (PAM conversation system) structure carries just the user’s password as a response from Ingres. To use other PAM modules (PAM_DCE, PAM_KRB5, and PAM_LDAP) with Ingres, it is expected that the response from Ingres to PAM will be something else. For example, it can be a certificate in the case of using RSA security, or PIN ( Personal Identification Number ) in the case of using smart cards ( ATM etc ), or Ticket granting tickets in the case of using Kerberos security etc… It all depends on which security mechanism is used at the customer’s site for user authentication. It appears that some changes will be required to the application defined callback function defined by pam_conv structure in the community implementation of PAM for these cases.

Proposal for PAM Integration

After reviewing the source code changes and additional testing, it was agreed that this should be implemented as a separate program (for the reasons mentioned below) from 'ingvalidpw' on systems that support PAM. The new program will be named “ingvalidpam”.

1. OS specific #ifdefs are not required.
2. The source file ingvalidpw.c is already becoming difficult to manage with tons of OS specific #ifdefs.
3. On UNIX systems that don’t support shadow passwords, there is no need for SETUID-root and SETGID-shadow as /etc/passwd file can be read by the world.
4. SETUID-root is not required on systems that DO support /etc/shadow passwords. This may be true for ingvalidpw as well. But the community implementation forces this check.

The 'ingvalidpam' executable will be pre-built and shipped with Ingres. There will not be any changes made to mkvalidpw script. The necessary Ingres build configuration (Jamdefs for example) files will be updated to include PAM library to build 'ingvalidpam' executable and the distribution/install scripts will need to be updated to add this new program. The source file ingvalidpam.x will reside under the directory clf/handy_unix_win, the current location of ingvalidpw.x. The common code for reading the user/password info and for debugging will be separated and shared by both 'ingvalidpw' and 'ingvalidpam' executables.

The service name will be defined as "ingres". For example, the PAM configuration for ingres on various Linux systems using ingvalidpam will have /etc/pam.d/ingres file with the following contents.

SuSE:

% cat /etc/pam.d/ingres

%PAM-1.0

auth include common-auth

account include common-account

Redhat:

$ cat /etc/pam.d/ingres

%PAM-1.0

auth required pam_unix.so

account required pam_unix.so

HP-UX/Solaris:

The service name "OTHER" can be used or "ingres" can be added which will also use pam_unix.1 module.

% cat /etc/pam.conf

OTHER auth required /usr/lib/security/libpam_unix.1

OTHER account required /usr/lib/security/libpam_unix.1

The Ingres documentation requires detailed update on configuring/testing Ingres for PAM.

Integration with Ingres GCS facility

No relevance has been found for the integration of PAM support in the GCS layer itself at this point as the implementation from the community uses the Unix PAM module that comes with the OS and not any Ingres specific PAM module for authentication. (For example, like the opensource project for postgreSQL for PAM support mentioned at Sourceforge [1]).

Additional References

There are numerous articles available online about PAM. Below are some URLs for additional reference.

User Authentication - HOWTO [2]

Gentoo-PAM-maintenance-project [3]

EnterpriseNetowrkingPlanet [4]

Sun website[5]

IBM website[6]

Sun developers website[7]

LinuxJournal website[8]

Aplawrence website[9]

Comptechdoc website[10]

Unixpapa[11]

Kernal.org website[12]

Conclusion

This article covers integration and testing of PAM support in Ingres received from the community using the PAM_UNIX module shipped with OS. The PAM_UNIX module provides authentication service by reading user/password info as configured in /etc/nsswitch.conf file for validating users. This submission from the community will require changes to support PAM modules other than PAM_UNIX. Further investigation/testing required based on the customer’s requirements.

The primary benefits of adding PAM support are:

1. One interface/program to support multiple security services (controlled by PAM config). Less ongoing maintenance should be required to support OS-specific nuances in user authentication (problems are reported with ingvalidpw on a fairly regular basis).
2. Lower security exposure because authorization program can run either with no special privileges or, worst case, shadow group privileges, whereas current implementation (ingvalidpw) must run as “root”.
3. Customers who want to implement PAM are supported by Ingres.
4. Use of contributed code (even if modified) demonstrates that Ingres Corporation is indeed interested in open source community contributions.

Ingres Corporation is interested in the feedback from the Ingres community. Please tell us about how you use PAM for the purpose of user authentications at your site. How would you see PAM integrated into Ingres? Is hard coding the PAM service name "ingres' as the default service name a good idea? How about using the existing PAM service names such as "login" that are already defined in PAM configuration file that comes with the OS by default. Your feedback is very much appreciated.

Please post your feedback to the Ingres PAM Discussion Page