[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20060702161137.GT1128@annvix.org>
Date: Sun, 2 Jul 2006 10:11:37 -0600
From: Vincent Danen <vdanen@...sec.ca>
To: owl-users@...ts.openwall.com
Subject: Re: tcb and friends with shadow-utils 4.0.12
* Solar Designer <solar@...nwall.com> [2006-07-02 10:26:06 +0400]:
> > ALT doesn't use SimplePAMApps' passwd program, but has his own (had to
> > poke around to find it).
>
> You're right. Sorry for the confusion.
>
> OK, if there's a problem compiling SimplePAMApps' passwd with gcc 4.1+,
> we'll find that out very soon and fix it.
Ok... =)
> > Now, I just want to clarify something and I'm far from a pam expert
> > here... but when you have /etc/pam.d/passwd and it's going through the
> > stack (ie. pam_passwdqc and pam_tcb) for the password section, is
> > pam_tcb modifying the shadow file or is the passwd program?
>
> pam_tcb does that. That's why you have to tell it to write_to=tcb.
Ok... I do have that in my system-auth file. So passwd doesn't do any
heavy lifting at all, it's essentially just a keyboard receiver and
everything gets passed through pam_passwdqc and pam_tcb to do the heavy
lifting/thinking.
Now I'm really confused. My forward-port of the tcb stuff for
shadow-utils shouldn't have any impact on this whatsoever... the likely
culprit would be within the tcb package itself (either the pam module or
a lib or something). That or with pam_passwdqc (although I think that
one should be ok because it seems to intercept after the first password
you type in... ie. if it's not strong enough you start again from step
1, but if it is, then it's job is done because I suppose the passwd
program would make sure the two entered passwords are identical and then
hand that password off to pam_tcb).
Hmmm... I wonder if crypt_blowfish might have something to do with
this. Maybe it's the crypt_blowfish in glibc (I put it in there a few
years ago always meaning to move to tcb, but this would be the first
time I've actually tried it).
Maybe I should try setting the password hash to md5 or crypt, just for
kicks, to rule that out.
> > My thinking is that pam_tcb tells passwd that it has the right guy...
> > either I authenticate with my password and or I don't, so passwd is
> > looking for a PAM_SUCCESS to come back to it, and when that's done it
> > will write the password. So I'm thinking that passwd actually does the
> > writing and pam_tcb doesn't actually touch the shadow or tcb files,
> > correct?
>
> No. The passwd program should not even know where the passwords or
> password hashes are stored; it is just a tiny wrapper around PAM calls.
>
> Besides, the PAM password changing stack may also be invoked from login
> services to force changing of expired passwords. The passwd program is
> not involved in this at all.
Right. You're right. Ok... I'm starting to understand this and it's
making me think in different ways. I'll track this sucker down. =)
Sorry for all the out-loud thinking, but that's what usually helps me
get focused on the right thing. And thanks for letting me use you as a
sounding board... =)
--
{FEE30AD4 : 7F6C A60C 06C2 4811 FA1C A2BC 2EBC 5E32 FEE3 0AD4}
mysql> SELECT * FROM users WHERE clue > 0;
Empty set (0.00sec)
:: Annvix - Secure Linux Server: http://annvix.org/ ::
Content of type "application/pgp-signature" skipped
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
