owl-users - Re: tcb and friends with shadow-utils 4.0.12

Openwall Project		/home Owl JtR Pro crypt pam_passwdqc tcb phpass scanlogd popa3d msulogin / Linux BIND / advisories presentations / services donations / wordlists passwords / community lists wiki CVSweb mirrors signatures
bringing security into open environments

Order Openwall GNU/*/Linux 2.0 on a CD with delivery worldwide

[<prev] [next>] [<thread-prev] [thread-next>] [month] [year] [list]

Date: Tue, 4 Jul 2006 08:28:17 +0400
From: Solar Designer <solar@...nwall.com>
To: owl-users@...ts.openwall.com
Subject: Re: tcb and friends with shadow-utils 4.0.12

I wrote:
> > OK, this suggests that the problem is in fact with crypt_blowfish or the
> > way it is integrated or compiled.  And I think that I know what it is -
> > most likely, you need to increase BF_FRAME in x86.S:
> > 
> > 	http://cvsweb.openwall.com/cgi/cvsweb.cgi/Owl/packages/glibc/crypt_blowfish/x86.S.diff?r1=1.4;r2=1.5
> > 
> > Sorry it did not occur to me to mention this to you before.

On Mon, Jul 03, 2006 at 10:02:11PM -0600, Vincent Danen wrote:
> I don't think that was the problem.

I am almost sure that it was.

> What I ended up doing was taking the patch that SUSE was using and
> re-adding a few bits (they never touched crypt/Versions so some
> symbols weren't being exported or available that pam_tcb wanted ...

Oh, that's not good.  It means that people can't compile pam_tcb on SUSE
Linux even though they (almost) have crypt_blowfish in glibc.  Maybe you
can contact SUSE folks (Thorsten Kukuk?) about that?

> After about a half-dozen glibc compiles and puttering around, bcrypt is
> working now (strange... I've had it for over 2 years and never even
> tried it so it's been broken all this time).

It might not have been broken all this time.  If the problem is what I
think it is, it should have appeared with your move to gcc 4+ only.

> http://svn.annvix.org/cgi-bin/viewcvs.cgi/releases/2.0-CURRENT/glibc/SOURCES/glibc-2.3-avx-suse-crypt_blowfish.patch?root=packages&rev=5738&view=markup

This confirms my guess.  This patch has:

-#define BF_ASM				1
+#define BF_ASM				0

This disables the assembly implementation, thus avoiding the problem
with BF_FRAME being too small.

I suggest that you drop this SUSE-derived patch and go back to our
recommended way of integrating crypt_blowfish (as described in its
README or as implemented in Owl), but increase BF_FRAME.

> Right now I'm having an issue with userdel complaining that it can't
> lock the shadow password file, so it's not deleting anyone.

Now that's likely a bug in your forward-port of the shadow suite patch.

> If nothing else, it's been a bloody challenge... =)

Perhaps we should do something to make this easier.

If newer gcc does indeed require a larger BF_FRAME (in fact, I recall
this being mentioned to me before), we'll increase the default.

Thank you for not giving up on this!

-- 
Alexander Peslyak <solar at openwall.com>
GPG key ID: B35D3598  fp: 6429 0D7E F130 C13E C929  6447 73C3 A290 B35D 3598
http://www.openwall.com - bringing security into open computing environments