On Jun 13,  8:46pm, Aidan Cully wrote:
}
} It strikes me that there's a possible compromise solution...  Provide
} a PAM library (solves the "player in the OS game" problem), but don't
} actually make any of the system utilities use it.  Instead, create a
} BSD-authenticator which speaks PAM, and make the system utilities use
} BSD-auth.

     Wouldn't work.  As others have pointed out in the past, there are
things that you can't do using BSD auth.  An example was that Kerberos
requires setting things in the environment of the app.  Since BSD auth
uses external programs, it can't do this.

} The thing that really irritated me about PAM (this is a fuzzy memory
} from at least three years ago) was that the external API was defined,
} but I didn't see any documentation on actually creating the PAM
} modules, and got the distinct impression that the internal API was

     There are some specifications for it, see:
http://www.opengroup.org/pubs/catalog/p702.htm

} not standardized...  I.e., it would be impossible to use the same
} source code to generate a PAM module for all the PAM-providing
} platforms (Linux, Solaris, etc.).  Can someone correct me on this?

     There are some minor differences between the Linux and the Solaris
implementations.  These are easily handled with #ifdefs.  As an
example, see pam_radius_auth at
http://www.freeradius.org/pam_radius_auth/ and look for if{,n}def sun.
The difference is only a handful of lines.  The bulk of the module is
for implementing the RADIUS protocol.  There really isn't that much to
the PAM protocol.  Note that PAM was origninally specified by Sun.  See
here for their document:
http://wwws.sun.com/software/solaris/pam/pam.external.pdf .

} On Tue, Jan 21, 2003 at 12:40:31PM -0800, John Nemeth wrote:
} >      There is the issue that a bug in a PAM module could cause a
} > security vulnerability in all the apps that use it.  There isn't much
} > that can be done about this, beyond careful coding and thorough
} > testing.  This is, of course, a problem with all library routines.
} > Since modules will be common and a lot of people will be using them,
} > there will be lots of people to search for and fix bugs.  Hopefully,
} > this will minimise them.
} 
} I don't like this line of reasoning...  It's one thing to make it in

     I'm not that crazy on it.  Obviously the best way to get security
is to have the modules written by advanced experienced programmers that
know how to write secure code.  Since everybody makes mistakes, this
code then needs to be looked at by other such programmers.  That's
where the above comes in.  Although, there are tools that can help, I
don't know of anything that can replace highly qualified programmers at
this time.

}-- End of excerpt from Aidan Cully