[nycbug-talk] Change password at next login?

[Miles Nordin]

>>>>> "ta" == Tim A <techneck at goldenpath.org> writes:

    ta> Well, I learned a lot about PAM. It's pretty cool.

cool!

    ta> I still can't get pam_passwdqc to enforce on expired passwords
    ta> being renewed via ssh logins though.

aaahh.  ah-hah.

    ta> I've added: password requisite pam_passwdqc.so enforce=users

    ta> to the seemingly obvious service files: /etc/pam.d/passwd
    ta> /etc/pam.d/login /etc/pam.d/sshd /etc/pam.d/system

oh!  oh yes!  because, you see, ... I think I remember this part.
Uh.. with PAM!, instead of changing, uh this, in n^2 places, you only
have to change it in n places.  or, was that ``instead of changing it
in n places, you change it in 1 place.''  Are you changing it in n
places or 1 place?

OH WAIT!  It doesn't work AT ALL!

oh it does work a little?  You're changing it in 2 places, it's
working in 1 place, n places are left to test?  Or n * m places left
to test?  How many places might be broken?  n * m - 2?  well, one
place is definitely broken.

I think you need to change it in o places, but you need to test it in
m places, and it's broken in x places where 1 <= x <= m - 1.  not
great.  BUT, as you can see, there is no exponentiation going on here.
Thank god for PAM!  not like before!

    ta> I ran strace on the sshd pid, reset and expired a pass, then
    ta> connected.  strace pauses at the password prompt though, and
    ta> doesn't continue until after the password has been changed.
    ta> The output does not indicate that passwd is being called.  So,
    ta> I'm guessing: something else is being used to call passwd?

try looking for libvoodoo_dl.la

    ta> some other system utility is being used to change the password
    ta> other than passwd?

does passwd still change passwords?

no, this is a serious question.  are you SURE passwd changes
passwords?  maybe it's invocating something else.

    ta>  From reading up on PAM, I'm guessing there are other pam
    ta> modules I can use to do this and more.

oh, sure, that's the ticket, MOAR MODULEZ!!

Seriously, this PAM stuff is garbage and always has been.  Their
pitch, to begin with, was, ``if you have n programs authenticating
(ssh, login, xdm, AFP, Samba, IMAP) and m types of passwords (crypted,
one-time S/Keys, tokens, smartcards with certificates inside,
kerberos), with PAM you can use n modules + m modules instead of
writing n * m bits of custom code.''

In practice, it falls on its face, constantly, yet everyone absolutely
REFUSES to see it!  S/Keys require challenging the user and getting a
response.  PAM has probably some API for passing messages that works
with login, but not with ANY of the other n programs---how do you pass
the challenge to an AFP user, an IMAP user, even an ssh user?  The PAM
problem-statement is misguided and ill-formed.  Or a Samba
user---OHWAIT! Samba can't accomodate S/Key at ALL because of its
quirky over-the-wire hashing nonsense.  Which brings us straight to
Kerberos.  This is clearly the password checking sso infrastructure of both the future and the past.  It predated PAM and will outlive PAM, so _surely_ PAM's n * m inclusive architecture is well-suited to implementing Kerberos, right?

Thanks to PAM, people no longer understand what *is* Kerberos.  They
think it's like a password storage back-end, a special more secure
LDAP-like thing for passwordstorage.  so if they let users type
plaintext or MITM-vulnerable SSL-encrypted passwords into IMAP and
then check these passwords on the IMAP server against a KDC, they
think they have ``kerberized'' IMAP, because this brokeass
implementation of Kerberos is necesaarily all that PAM can allow.
Kerberizing something used to mean altering the protocol itself so the
user logs in at the IMAP client and then passes tokens instead of
passwords over the IMAP session.  When I set up BSD/OS in 1995, all
the r* tools and telnet and login and xdm were all Kerberized, and
thre were cookbook instructions for setting up a KDC that I completed
in an hour or two.  Many protocols have defined extensions for
kerberization which aren't used any more because everyone is in PAM
lala-land.  How about the idea of tickets expiring and renewing?
PAMification of login gets you a ticket, right?  But will PAM kill the
session when the ticket expires?  There is a rather advanced though
often broken, underimplemented, underused ``sessions'' mechanism in
Unix so that all the descendent processes of a particular password
presentation can be killed at once, so we ought to wish for this---if
done right, it would work SYSTEM-WIDE---when your TGT on a client
expires, all IMAP sessions and NFS rights and ssh logins and webapps
all magically expire at once.  Will PAM even help you renew your TGT
(assuming PAM kludgily gives you a TGT at all, rather than simply
checking the password in Kerberos and feeding the TGT to /dev/null),
or do you have to use an un-PAMified raw Kerberos program to do that?

PAM isn't cool.  It's also full of bugs, and its behavior can be
reliably known only by observation which is exactly the type of
quirkyness what you *DO NOT* want from a subsystem meant to be
checking passwords!  no, you don't have to write n * m bits of special
code, but everyone has m broken applications, and n * m things to test
looking for surprise security problems.  and, as you found, debuggers
don't work well any more, source code is hard to find, and the
internal behavior of modules is not documented, only rather optimistic
fantasies of how to configure the module are sometimes partially
documented.  PAM's an embarassment.

 http://groups.google.com/group/mailing.openbsd.tech/browse_thread/thread/5ea7de6c58f08d54/68ba289c9dad5514?lnk=gst&q=PAM+%22buzzword+compliance%22#68ba289c9dad5514

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 304 bytes
Desc: not available
URL: <https://lists.nycbug.org:8443/pipermail/talk/attachments/20080429/16fc76b7/attachment.bin>