Warning: Undefined array key "rcommentid" in /www/blog/wordpress/wp-content/plugins/wp-recaptcha/recaptcha.php on line 348

Warning: Undefined array key "rchash" in /www/blog/wordpress/wp-content/plugins/wp-recaptcha/recaptcha.php on line 349
OpenPAM – May Contain Traces of Bolts

OpenPAM

In late 2001, ThinkSec AS, a small infosec consultancy I worked for (and had co-founded), was contracted by Network Assosciates (now McAfee) to complete FreeBSD’s PAM integration, as part of a DARPA initiative to improve security in F/OSS.

Juniper Networks had previously sponsored John Polstra to import Linux-PAM and a small set of modules, but only a few programs were “PAM-aware”. One of my goals was to push PAM into anything that needed to authenticate users; of particular interest was OpenSSH, which had PAM support for the SSH1 protocol but not for SSH2. Another goal was to move widely duplicated authentication-related logic into PAM modules1. Yet another, more prosaic task was to fix known bugs in Linux-PAM.

When adding PAM support to third-party code which also ran on platforms with a different PAM implementation (specifically, OpenSSH on Solaris), it was important not to rely on features which existed only in Linux-PAM or in FreeBSD extensions. I therefore started writing a dummy PAM library which defined all the macros and functions described in the XSSO but didn’t actually do anything; compiling applications and modules with this library instead of Linux-PAM would serve as a purity test of sorts.

I soon discovered that in order to get meaningful results, I needed to at least get to the point where the library loaded modules; and to get to that point, I needed to implement a sufficient fraction of the functionality applications used before invoking service functions so they wouldn’t bail before they got there. This had the added advantage that I could not only verify that the code built with a “clean” library, but also validate both what applications and modules passed to API functions, and what modules returned to the application. I soon found that my “purity test” had turned into a working implementation of a significant subset of the PAM API.

Around that time, I finally got fed up with the (then) execrable quality of the Linux-PAM code2, and decided to implement the entire API and get rid of Linux-PAM altogether. By March 2002, FreeBSD had switched from Linux-PAM to OpenPAM. NetBSD adopted it in 2005, and Mac OS X in 2008.


1 Pardon my RAS syndrome.

2 I’m sure Linux-PAM has improved greatly since then, but back then, it was a disaster.