Re: lib/40599: MKKERBEROS=no without MKPAM=no yields a broken system

[David Holland <dholland-bugs%netbsd.org@localhost>]

The following reply was made to PR lib/40599; it has been noted by GNATS.

From: David Holland <dholland-bugs%netbsd.org@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: 
Subject: Re: lib/40599: MKKERBEROS=no without MKPAM=no yields a broken
        system
Date: Sun, 15 Feb 2009 09:18:05 +0000

 On Tue, Feb 10, 2009 at 02:45:00AM +0000, dholland%eecs.harvard.edu@localhost 
wrote:
  > >Fix:
  > 
  > First, make things not fail miserably; that is, the pam libraries
  > should survive modules being missing without dumping core. This is
  > pretty basic.
 
 This appears to be a lack of error-checking in xdm.
 
  > Then, either the ritualized standard invocations in /etc/pam.d should
  > be installed without Kerberos when MKKERBEROS=no, or they should be
  > constructed robustly so that they will skip Kerberos if Kerberos is
  > not installed, without at the same time failing open under other
  > failure conditions. The second of these is obviously preferable, but
  > my (perhaps limited) understanding is that it is beyond the ability of
  > PAM.
  > 
  > I do not think it reasonable to expect the user to edit the muck in
  > /etc/pam.d to build a system without Kerberos; but in any event it is
  > certainly unreasonable to expect it when the need to do so is not, as
  > far as I can tell, documented.
 
 After discussing this with jnemeth, it appears the best approach is
 probably to change things around so that a missing module is replaced
 with a builtin module that always fails. This cannot make the
 configuration *more* permissive so can't be construed as failing open,
 but in practice will make missing kerberos modules harmless without
 any need to edit /etc/pam.d.
 
 It isn't that difficult a patch, either.
 
 I will run this by tech-security.
 
  > The real (and more controversial) fix of course is to remove PAM and
  > replace it with something that works.
 
 Coming up with something clearly enough better to gain traction (since
 PAM has become pretty much standard) will be difficult.
 
 In case anyone disposed to think about it is reading this, I have two
 observations to make:
 
    (1) Having the process that faces an unauthenticated user be
        maximally privileged, or for that matter privileged at all, is
        not desirable. But rearranging the world so this isn't
        necessary is a big step.
 
    (2) One of the less obvious problems with PAM is that it is based
        on a specific mechanism, that is, stringing together chains of
        modules, and you configure it by manipulating the mechanism
        rather than by specifying a policy you want it to implement.
        (It is somewhat like System V init in this regard.) Exposing
        the mechanism like this makes it unnecessarily difficult to
        work with.
 
 -- 
 David A. Holland
 dholland%netbsd.org@localhost