Subject: Re: PAM
To: None <current-users@netbsd.org>
From: Ross Patterson <Ross.Patterson@CatchFS.Com>
List: current-users
Date: 09/26/2002 12:17:55
On Wednesday 25 September 2002 09:01 pm, Dan Melomedman wrote:
> I don't mind the paths as much as I despise hard to understand
> configuration files. Also configuration files should be easily parseable
> and editable by software, not only humans.

The examples of parseable-but-not-understandable config files are legion, but 
we can easily take Apache and sendmail as two illustrations of why both 
aspects are important.

> > I notice that under Solaris, all sorts of fields are required for each
> > entry.  There must be a somewhat less complex way of setting up modules
> > for incorporation.  I haven't played with Linux sufficiently to see how
> > their PAM works.

In Linux-PAM 
(http://www.kernel.org/pub/linux/libs/pam/Linux-PAM-html/pam-4.html), each 
entry in the file consists of only three or four required tokens (depending 
on whether you use per-service or monolithic config files) and optional 
parameters for the specific module.  You can put together a reasonable 
config file for one service with less than a dozen lines of text.

> Does the system really need to do so many things? All I want is one
> module for one type of authentication, with two deterministic resutls -
> success or failure. Simple, easy, and uh, sufficient. Keep it simple,
> stupid.

Here's one example, from a real-world corporate-IT environment.  One of my 
former employers was a largely-Microsoft shop, with a centrally-managed MIS 
operation and roughly 20,000 staff, each enrolled in one of three 
geographically-designated MS-Windows "domains".  All sorts of applications 
required logging in, and by edict all of them must use the domain controllers 
as the authentication service.  Why?  Because when someone leaves the 
company, their access to *all* services can be turned off immediately and 
definitively.  The only allowed exceptions to this rule were engineering-lab 
systems, which were presumed to be insecure and managed ad-hoc.  

The PAM-LDAP module made it possible to integrate Linux systems into this 
environment, because in a rare instance of clear vision Microsoft allowed 
LDAP access to their Windows domain controllers.  Becuase of PAM's model of 
return values, we were able to set up configurations that, for example, 
allowed root to log on from the physical console without a password, but only 
when the domain controller was unavailable.  Some folks will scream that 
that's a *very* insecure situation, but that's a matter for the local 
administration to decide.  In our case, those systems were located inside 
physically secure facilities, and the system managers believed that access to 
the consoles was protected well enough to make it appropriate.

-- 
Ross A. Patterson
CatchFIRE Systems, Inc.
5885 Trinity Parkway, Suite 220
Centreville, VA  20120
(703) 563-4164