Re: The current (not existing) PAM policy
On Thu, Mar 13, 2003 at 08:56:58PM -0600, Steve Langasek wrote:
>
> Attached is a quick proof of concept for using the @include (not
> $include, sorry) syntax in /etc/pam.d for a Kerberos/Unix site. A
> significant amount of work is required to massage this into something
> that Debian could ship, but it should provide a starting point for
> someone with the time and ambition to take this on. Using this
> approach, some apps will still need to provide their own configs (ssh
> and su being two examples -- login is left as an exercise for the
> reader), though greatly simplified, and others don't necessarily need
> separate config files at all (passwd is a good example here, I think),
> in which case a .ex file seems reasonable.
>
> The ideal solution has common-* as debconf-managed non-conffile config
> files. Under NO circumstances should they be made conffiles, since the
> entire reason for the existence of these files is to make the system
> more *friendly* for admins who don't use the defaults. ;)
>
> --
> Steve Langasek
> postmodern programmer
I recently fielded some questions on using OpenLDAP and Kerberos as user
management and authentication in debian-user. Not much response there,
but since this is directly associated I decided to take a stab at how to
setup login and wdm for the PAM setup that Steve is recomending. I have
attached another version of his pam-revamp.tgz with my changes for
reference.
For login I took the original /etc/pam.d/login file and pulled it apart
replacing the sections that could use common-auth, common-account,
common-session, and common-passwd. Steve's current version uses
pam_krb5.so extensively, so I puzzle at how to handle the login.defs for
this. Is login.defs a conffile? If so, that bites, and will have to be
changed, otherwise the login utility could not 'automagically' use
pam_close_session() and cleanup when the user install Kerberos.
For wdm I took the original /etc/pam.d/wdm and replaced the original
lines with the necessary includes. This one is stupidly easy and does
not seem to have any special cases. However It ocurred to me that a user
using xdm, wdm, gdm, and family across XDMCP are passing their passwords
in the clear. If anyone has any suggestions there, let me know. This is
a real pain, and a major security concern for mass X-Terminal
installations.
I also noticed that the password facility was not defined in Steve's
version. I added a common-password file and configured /etc/pad.d/passwd
to use it. Presumably when installing something like SRP the
common-passwd file could be used to setup the password migration. This
may also apply to things like Kerberos and LDAP based authentication
schemes.
I noticed that /etc/pam.d/other in Steve's version did not use the
include scheme he recommends. I think it would be suitable that
/etc/pam.d/other use the scheme as well. This will force undefined PAM
aware applications to use the same scheme as the administrator has
installed.
I have quite a lot of sid installed and have accumulated the following
files in /etc/pam.d/
chfn cvs other passwd.dpkg-old su xscreensaver
chsh login other.dpkg-old ppp wdm
cron login.dpkg-old passwd ssh xdm
I will happily work through these rewriting their base versions to use
the scheme Steve has proposed. However I am no expert on PAM so
suggestons are welcome.
On researching this further this morning I found a Debian-PAM-MiniPolicy
in the documentation for libpam0g. I believe it would be appropriate to
use this as a base for drawing up any further Debian-PAM policy.
Any suggestions or ideas are welcome. Any thoughts on setting this up to
use both LDAP and Kerberos together would be great. I have often hoped
Debian could be setup to use both by default.
Thanks,
Matthew P. McGuire
So yeah, at times I can be a security nut.
But that's why I like Debian. :-)
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Matthew P. McGuire <gray@shadowglade.net> 1024D/E21C0E88
CB82 7859 26B2 95E3 1328 5198 D57A D072 E21C 0E88
When choice matters, choose Debian.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Reply to: