[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

PAM/NSS Policy et al



Hello!

While trying to configure and understand pam autentication and name
service switch in the context of ldap I had a hard time to find clear
and complete documentation, configuration examples and aplication
hints.

As it seems, pam autentication is yet standard on Debian systems,
however the debian policy does not cover it (yet), neither nsswitch
configuration so I want to propose some issues.

Disclaimer: Please understand that I am somewhat novice to these
themes, so please be so polite to ignore my nuisances.

* General questions

It seems to me, that pam and nsswitch resolve some issues in parallel,
so there would have to be made a choice how to deal consistently
without loosing flexibility.  I am thinking about session managment,
where some pam modules provide information about, e.g. home directory
and login shell, while nsswitch serves the same purpos.  With
retrieval of autentication information we have the same situation, you
can go either way: nss or pam.

Pam seems not to reimplement standard autentication completely.  While
the shadow-suite sets some standards (login.defs) over standard login
handling, pam seems not to implement the whole set of it's features -
correct me if I'm wrong: root path vs user path (ENV_[SU]PATH) is not
equally handled.  There are other examples, like password changing,
etc. which are not/not yet implemented in pam, or where the pamified
program versions are not installed.

* Proposal

A policy chapter or document should be created, where authentication
and name service is thoroughly covered, so that package maintainers
can orient themselves of how to (re)configure their pieces of
software, and from where they can derive the TODO's to make them
compliant.

PAM authentication and NSS auth-information retrieval should be the
default configuration, while allowing to substitute it for the shadow
and the standard passwd suite as options.

The default PAM/NSS configuration should emulate the shadow suite.

Each pam/nss/sasl module should install a defined default
configuration, giving reasonable "best" security to the system.  The
configuration script should allow (see later) to modify some
parameters of the authentication configuration in a standardized way.

Sources of nss/pam information (slapd, db2, smb) should also come with
reasonable "best" security preconfigured (slapd installs by default
without access restrictions to smb-passwords).

A set of standard programs should be written, which ONLY rely on
PAM/NSS, so that the full power of their modularity can be exploited.

Candidates are: login, passwd, chfn, chsh, sudo, su, etc. (if not yet
done!)

Especially information storing (passwd, chfn, chsh) shall be included,
so that credentials can be updated in parallel.

If not the case yet, "getent" or a similar utility should be used as
the standard way (and mentioned as such) to retrieve name service
information. I stumbled over dh_make, which goes through a long and
fixed ordered list of individual queries to obtain my Full Name, while
this could be done more easy and compliant to my systems nss search
order configuration via "getent passwd $LOGIN".


* PAM documentation and configuration handling

** Drawbacks

The original PAM Documentation is very good and creates some kind of
standard in the reference part of the modules.  However this standard
is not taken up by the newer pam modules and ocasionally you have to
go to the c-sources to know which pam functions they implement.

On the other side, it is not clear which applications use pam, and
which pam functions are used by them.  So the pam.d directories shows
entries in some configuration files, which never will be called by
aplications.  This of course tends to obscure the meaning of the
configuration file.

The original "other" configuration is "wide open" explicitly against
the recomendation of the "Pam Systems Administrators Manual".

** Proposal

A pam module must install a cross reference documentation for itself,
similar to the original module documentation, to comply with the
policy.

Each application which uses the pam library *must* provide
documentation which states *which* pam routines are used.  If pam is
not used in all aplicable cases, the exceptions also have to be
documented.

Each autentication/nss affine application which does *not* use pam/nss
*should* state this fact, at least in the README.Debian file.

Each application using the pam library *must* install a configuration
file in the pam.d directory, which generates a default compliant
configuration for this aplication.

  Don't know what to do with different applications with the same
  service name (configuration file), maybe a authoritative list of
  service names should be maintained, at least for Debian.

A convenient place for the application to place it's pam-usage
information is the pam.d configuration file, if posible in a parsable
way, so that configuration scripts can rely on the information.

It would be nice to have a tool which scans a pam module for the pam
routines it provides (elf can do that, does it?) and writes them to
stdout.  It would of course also be nice to have each pamified
aplication have a command line option, showing the pam routines it
uses.

Given the former two or three tools/functionalities, it would be able
to write a configuration tool for each pam module, which checks its
applicapility for each installed service (pam-application) and
installs a configuration line in the corresponding service
configuration file.

This utility should:

     - install standard modules options without questions
     - install optional pam-module configurations after confirmation
       from the installer or
     - install a "best security" configuration if non-interactive or
     - install a commented out configuration line and notify the
       administrtator.
     - allow the administrator determine level (order) and action of
       the module, as well as eventually establish the provided module
       options. The level can be given as a number, similar to the
       selection of the ispell dictionary sequence.
     - be usable to reconfigure the service files.

Another issue with pam modules is logging.  The log format should be
unified, so that the administrator can identify wether it is the pam
library itself or a module, and which pam module issues the message
(if we are using a pam stack).

In especial with stacked autentication modules it is of use to know
*which* module of the stack has finally given the authorization.  This
can reveal security setup faults.  Actually the modules only log
failed autentication, but not granted autentication.  This can be
changed in *some* modules using the "debug" option.  On one hand a
"verbose" option would be better for this issue, so one does not have
to clutter up syslog with debug messages when tracing authentication,
on the other hand each pam module should be required to be able to
generate this message to be compliant to Debian.


* Name Service Switch

As I have even less experience and less documentation digested with
this, this section stays almost empty.

However the obvious thing is to define the way, nsswitch.conf is
maintained.

If somebody installs, lets say, libnss-ldap, a proper modification to
this file has to be made, and the adminstrator has to be able to
select the databases affected and the order of search.

On the other hand, all Debian utilities which use the system databases
have to be revised, so that they access uniformly to them via libnss.
See my example about dh_make.

This issue should really be addressed in the main policy manual, so
that package maintainers and builders are aware.  I'm saying this as a
Newbie-Unix-administrator, as we are the most out there who are
installing a Debian computer.  Nobody told me about nss, and the
"books" are full of "grep $USER /etc/passwd" ;-) Help us to learn
"good practice" from the start.


* OpenLDAP

When installing slapd and openldap and maybe other ldap before, etc. I
found myself with the fact (after strace-ing ldapsearch), that
openldap looks for /etc/openldap/ldap.conf, which is identical to the
file in /etc/ldap/ldap.conf, with the diference that /etc/ldap/* get's
configured to my needs by slapd and the other stays clean.  The point
is, that the tools do not find their configuration because they use
other directory then debconf.  While this may seem a mere concern of
the package maintainer, it shows also the need for a, surprise!,
ldap-policy.

Other example is, that the nss and pam modules for ldap utilizan /etc/
for their configuration files, while this could maybe logically fit
into /etc/ldap too.

The security concern is mentioned already: while a lot of schemes are
supplied for slapd, only *one* access restriction politics is given -
for userPassword.


**Proposal

	- All ldap related programs shall use /etc/ldap/ for their
          configuration files, *and* reuse existing files.  For this
          reason, a configuration file nameing scheme should be
          pointed out.
	- Debian should adopt the Domain-Component notation as
          standard, easying the standard setup of a server and of the
          clients, by using known information items - in this case the
          domain name of the machine.	
	- Each scheme installed should be acompanied by a
	  corresponding security setup, and maybe the installation
	  script should take care of it.  Schemes for which a security
          setup is not (yet) available shall not be installed in
          /etc/ldap/schemes, but in /usr/share/doc/<package>/examples

* Sasl

I know even less about sasl... Tell me how it fits in


* Maildir Off Topic

The Policy states, that /var/mail is the standard mail spool.
Probably this issue should be revised, giving ~/Maildir/ at least an
optional status.  Nowadays probably a wealth of Debian Machines, more
than other distribution are using Maildir aware MTA's and MUA's.

There should be a note in README.Debian of each MTA and MUA if it is
Maildir and/or /var/mail capable, and maybe a system configuration
choice should be made available via debconf or the like, respected by
packages capable of both posibilities. Packages which are not
compatible with the actual system mail directory setup should refuse
to install or configure.

An example is Kmail, which is not Maildir aware.  However there is a
script available (basically from the qmail software, wrapped by me)
which converts the Maildir contents to a /var/mail/<user> mailbox, and
which can be plugged into the retreival mecanism of Kmail. Something
like this could be done either way when packaging a MUA or MTA.


* My personal motivation

While installing more and more Debian Systems, mostly in small and
heterogeneous Linux/Microsoft networks, I face the fact, that Debian
configuration is much more work (albeit less trouble :) then MS
installation.  In my context - Nicaraguan small business and tecnical
universities, where on the one hand there ARE a lot of computers, but
on the other hand it is dificult to get qualified IT personal, this
reduces the chances of placing Linux "in the market" almost to zero -
everybody fears, that when the "chele" (my person) goes away, there
will be no one left to manage the beast.

Free Software is surely a great potential, especially in "development"
countries, where it can help with the apropiation of the employed
tecnology itself, in contrast to propietary systems, which tend to
increase dependence, curiously by the side efect of (I know this is
not the right term) piracy: As propietary software is practically
gratis, it is very widespread, for the corresponding industry this
means a costless training and propaganda system. Once forced to use
the software profesionally, the user yet is locked in into the
propietary system.

Of course there is the other argument, that low profile and obsolete
Hardware can nowadays only be exploited by Open Source products, I can
even give you some own examples: http://sam.uni.edu.ni is a
50Mhz/32MByte 486 Olivetti PC and running since half a year, and there
is a masquerading firewall with a similar machine under heavy duty on
the León UNAN University net, aliviating the lack of IP Numbers for
about thirty Window machines, running over a year practically without
administrative intervention, not to speak of the computer oldtimer
museum I am hording at home.

However I consider this a foul and lazy point of view.  Industry,
government and people by themselves are buying the newest tecnology
computers on a daily basis, and where Information Technology is to be
playing a role, it will be on the most actual hardware.  While
personally beeing a computer recycle fanatic I try NOT to convince
anybody here, that this is the better solution, because people deserve
to be on top tecnology and knowledge to overcome the economic and
social problems with which they are struggling.

Now, coming back to the original theme, I am working on creating a
project which uses Debian and some of the wonderful tools existing on
it to form a set of installation and configuration tools, which allow
people to build and maintain computer network "cells" out of the box
with minimal effort and time, and a given set of functionality and
applications.  These "cells" should be private networks which can be
"pluggable" into the Internet or any other "comunity network" via one
of the machines, such forming parts of bigger networks.  The target
are computer classrooms, Internet Cafés, small and middle business
networks, comunity groups etc.  

While exploring this task I found myself faced with the problems
discribed above.  Please contact me, if you are interested in the
project, or if you are doing something similar.


Best Regards,

     Georg Lehner, alias Jorge-León



Reply to: