Hi Matthew, On Sat, Mar 15, 2003 at 11:07:17AM -0500, Matthew P. McGuire wrote: > 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. I'm confused. What does login.defs have to do with PAM? If login needs a configuration option to tell it to call pam_close_session(), I think that's a bug. (Also, ccache cleanup should be done with pam_setcreds(PAM_DELETE_CRED), not with pam_close_session().) BTW, your pam.d/login file contains these lines: @include common-account # This line is replaced by the above include. # account required pam_unix.so This seems overkill to me; if you comment the account stuff out altogether, it will fall back to /etc/pam.d/other (which ends up being loaded by libpam no matter what). In some of the other files, I did use a @include even though it was the only line present for a given stack type. The reason for this is that the files in question contained other *commented* examples that users might uncomment to ill effect if the @include wasn't there. > 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. This is orthogonal to PAM. > 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. This is because I have not found any applications yet that *need* anything more than a sane default in /etc/pam.d/other for password handling. I find it extremely unlikely that any app shipped with Debian would require (or merit) a password changing policy that differs from the site policy. As a result, neither /etc/pam.d/passwd nor /etc/pam.d/common-password is necessary. > 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. The presumption was that /etc/pam.d/other would also be a centrally managed non-conffile. I don't think it's advisable to make /etc/pam.d/other depend on external files, given its key role in PAM's fallback mechanism. > 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. The first step is to go through all of the packages in sid that depend on libpam0g and find out if any of them provide PAM configs that cannot be satisfactorily addressed by the proposed include scheme. Once we have an include scheme that's confirmed to work, a patch against the pam package seems to be in order. > 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. Sounds reasonable. > 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. Debian should still use pam_unix by default, but this reorg paves the way for letting users easily configure the authentication method of their choice. -- Steve Langasek postmodern programmer
Attachment:
pgpEqnqph0XAz.pgp
Description: PGP signature