[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: lib/40599: MKKERBEROS=no without MKPAM=no yields a broken system
The following reply was made to PR lib/40599; it has been noted by GNATS.
From: David Holland <dholland-bugs%netbsd.org@localhost>
Subject: Re: lib/40599: MKKERBEROS=no without MKPAM=no yields a broken
Date: Sun, 15 Feb 2009 09:18:05 +0000
On Tue, Feb 10, 2009 at 02:45:00AM +0000, dholland%eecs.harvard.edu@localhost
> 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
> 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
David A. Holland
Main Index |
Thread Index |