Re: The current (not existing) PAM policy
On Sat, Mar 15, 2003 at 01:59:30PM -0600, Steve Langasek wrote:
>
> 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().)
Interesting. I got the idea from the current /etc/pam.d/login file. Here
is the comment I was worried about.
# NOTE: If you use a session module (such as kerberos or NIS+)
# that retains persistent credentials (like key caches, etc), you
# need to enable the `CLOSE_SESSIONS' option in /etc/login.defs
# in order for login to stay around until after logout to call
# pam_close_session() and cleanup.
I do not know how relevant it is but I thought I should bring it up.
> 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).
The common-account file should contain the same line so that the account
section is run correctly. Essentially I moved the line, and commented
the original for ease of use.
> 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.
I was unaware that other provided fallthrough for undefined sections in
other files. This was not readily apparent or explicit. I used the
@include option repeatedly because I prefer explicit references to
implicit ones. One of the reasons I like the init.d system we currently
use is the ease in which someone can trace what is happening. In a sense
this is an ease of use idea for new users to PAM. I only provided the
original line in a following comment for people expecting to see the
line but not expecting the @include line. Most of this also boils down
to a misunderstanding on my part, but I will go into that in a bit...
> > 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.
Valid point, but unless I am wrong this is really bad. For instance, the
city of Largo, FL currently uses a large setup of cheap X-Terminals, and
it worries me that the authentication mechanism is possibly insecure. I
would like to use the same setup using Debian but I do not know of a way
around the secutirty hole. Definately orthogonal, but food for though.
> > 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 will come back to this, more of my misunderstanding...
> > 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 created common-password in the event the administrator is arranging an
authentication transistion. SRP provides a couple of modules that allow
the user to login and then have to reset their password. Once reset the
new passwords are in the new SRP setup. You would do this until all of
your users have reset their passwords. Then you swap things around and
the new authentication works. At the time creating common-password
seemed the only solution to the 'problem'. Your probably thinking,
"What 'problem'? Are you nuts?"
Ok, I completely missed that fact that you want to use /etc/pam.d/other
as a non conffile so that the administrators could use it freely. So
since I didn't want to depend on it, I solved the 'problem' by providing
a common-* file for each stack section. However on considering both I
think it would be better to use common-* files explicitly as opposed to
implicitly using /etc/pam.d/other. Besides having all four common-*
files makes it easier look at. :-)
>
> 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.
No problem, that sounds fun. How would you suggest I get the list of
packages that depend on libpam0g?
> > 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.
Exaclty. My real wish is to see a set of .udebs for each authentication
style. That way the installer can setup up the desired one first and
avoid migration problems. This could also work well if you want to
quickly add machines to a network that already uses something like
Kerberos or LDAP. Man that would rock.
Steve, I have some questions for you regarding the pam_krb5.so module.
Mind if I run them by you in a seperate email? They do not really apply
to PAM itself.
Thanks,
Matthew P. McGuire
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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: