--with-cracklib (phase 2)

Andrew Bartlett abartlet at samba.org
Sat Jan 18 00:23:31 GMT 2003

On Sat, 2003-01-18 at 09:32, Pierre Belanger wrote:
> Hello,
> >>
> >>Issues & questions:
> >>
> >>- Will we ever see more work on cracklib, nothing changed
> >>   since 1997. We know we need to add an "API" that doesn't
> >>   use "getuid() / getpwuid()". If Alec and/or Chris don't
> >>   want to add an API that doesn't use the get{pw}uid(),
> >>   we can:
> >>
> >>   1- Add a patch to cracklib in a "contrib" directory, link
> >>      Samba with "libcrack.a"
> >>   2- Commit an API in "Samba", still link with "libcrack.a"
> >>      for the rest of the functionnalities.
> >>   3- Commit a "samba-cracklib" in SAMBA_X_Y , i.e. fully
> >>      integrate samba-cracklib in Samba (no more
> >>      fprintf(stderr,...), etc), when possible use Samba's
> >>      "string" functions instead of cracklib's original.
> >>      Don't use sprintf, use Samba's snprintf, etc.
> > 
> > 
> > Yes, if cracklib using stdout/stderr as it stands, then we have no
> > choice but to either isolated it to a 'helper' program, or integrate it
> > into Samba.  I think I prefer integration.
> > 
> "integration" also means to add at least the "packer" program
> needed to create the dictionnary with a "simple" index. Might
> as well put them all in .../samba/bin/cracktools/... ???
> Well, if we integrate everything, how about "smbcracklib"
> or "smb-cracklib" with options to pack, unpack, etc ? Something
> like:
>                                            Cracklib equiv.
>    -D Dictionnary path (could be taken from smb.conf ?)
>    -P pack dictionnary                     packer
>    -U unpack dictionnary                   unpacker
>    -l test passwords                       testlib
>    -d turn on debugging (if needed)
>    -w print position of a word             teststr
>    -n print word at a specific position    testnum
> I have no preference to what should be included or not, but
> the "packer" feature must be included.
> >>[Q] What do you think is the best to do? I don't like #1.
> >>#2 is possible, we'll probably endup with our own re-written
> >>"fascist.c" .
> > 
> > 
> > Assuming the license is compatible, then I think this is the best
>  > course of action.
> > 
> Is there a "licence Guru" that can give us a confirmation?
> The LICENCE is attached in this mail.
> I don't see a problem with the following words in the LICENCE:
>    "plus the right to make reasonable modifications"
> We're not going to make that many modifications.

The artistic license is not compatible with the GPL.  As such we cannot
distribute Samba with this code, but we may link to this code under the
'operating system exception'. 

As such, I would suggest that we either look into GPL-compatible code of
a similar nature or we instead create a separate project to produce a
stand-alone executable interface (much like the one heimdal kerberos
uses), and have samba know how to use it.

> > 
> >>Some "meat" now, not a big piece!
> >>
> >>Added the following code in smbd/chgpassword.c ~ line 973 :
> >>
> >>   #ifdef CRACKLIB
> >>     if (msg = NewFascistCheck(new_passwd, CRACKLIB_DICTPATH,
> >>       pdb_get_username(hnd), pdb_get_fullname(hnd))) {
> >>
> >>       DEBUG(0, ("Can't change password - "
> >>                 "Cracklib returns: %s\n", msg));
> >>       return NT_STATUS_ACCESS_DENIED;
> >>   /*    return NT_STATUS_PASSWORD_RESTRICTION; */
> >>
> >>     }
> >>
> >>   }
> >>   #endif

In the meantime, I'll probably use this for my private installation, but
it's looking like this will be a bit more difficult than we originally

> >>[Q] Do we want to be able to configure the dictionnary name
> >>     within the smb.conf (char *) or "hard-coded" in cracklib?
> >>     Perhaps we want to be able to specify multiple directories
> >>     (char **). npasswd uses "(char **)" (mutliple). I have
> >>     no preference.
> > 
> > 
> > Given the number of platforms we run on, then configuring the dictionary
> > name would be 'a good idea'.  I don't see the need for multiple
> > dictionaries.
> > 
> I agree on both of your comments.
> >>
> >>[Q] Is NT_STATUS_ACCESS_DENIED the right value to return
> >>     when "cracklib" "finds the password" in the dictionary?
> > 
> > 
> > No, we should match what NT returns.  You figure this out by grabbing 
> > CVS ethereal, and decoding the password change.
> > 
> > http://msdn.microsoft.com/library/default.asp?url=/library/en-us/mschap/mschap/mschapsrvchangepassword.asp
> > 
> > Gives you a good idea what MS's internal functions do here - and this
> > maps quite well to the wire actually.
> > 
> > In this case NT_STATUS_PASSWORD_RESTRICTION would be a good choice.
> > 
> Thanx for the info.
> >>[Q] Is it possible to send back a real message? It could
> >>     be "The specified password is invalid. Please choose
> >>     a password not based on a dictionnary word" or
> >>     "password not long enough - minimum X characters", etc.
> > 
> > 
> > It's not possible, the protocol just doesn't have a place for it. :-(.
> > 
> Too bad ;-) How about trying to send a "POPUP" Window on the Windows
> machine? I guess it's possible if the user is already logged in,
> but if the user is not logged in yet, i.e. I'm talking about the
> situation when you first boot up your computer and you're forced
> to change your password *NOW* before you can actually "login"
> on the network.

That would depend on how the messaging system on NT works.  You can
certainly send a message, but I don't think it's a good way to get
reliable information to the user.

> >>     When I change my password here @ work (with a Windows
> >>     backend domain controller), I can't take any of my
> >>     previous ~ 3 passwords. I do get an "understand" error
> >>     message. Is everything needed to send back a "good"
> >>     error message already in Samba? If so, how? if not,
> >>     well I might need to install a good sniffer and read
> >>     a few more documents to understand "windows protocol"
> >>     unless someone here already knows how to do this.
> > 
> > 
> > I would like to see what it's doing - grab CVS ethereal and decode the
> > password change, see what goes where.
> > 
> Will do once cracklib is ready to be integrated. I think I do have
> plenty of work to do now ;-)
> > It's quite possible that the password restriction is being partially
> > enforced on the local machine.
> > 
> I asked myself that question for a brief moment while I was writing
> my previous mail. I think your right, just to be sure I'll grab
> "CVS ethereal" and make sure there's not something hidden somewhere ;)
> Thank you very much for your *valuable* comments!
> Regards - Again, enjoy the weekend.
> Pierre B.
> ----

> (*
> This document is freely plagiarised from the 'Artistic Licence',
> distributed as part of the Perl v4.0 kit by Larry Wall, which is
> available from most major archive sites
> *)
> This documents purpose is to state the conditions under which these
> Packages (See definition below) viz: "Crack", the Unix Password Cracker,
> and "CrackLib", the Unix Password Checking library, which are held in
> copyright by Alec David Edward Muffett, may be copied, such that the
> copyright holder maintains some semblance of artistic control over the
> development of the packages, while giving the users of the package the
> right to use and distribute the Package in a more-or-less customary
> fashion, plus the right to make reasonable modifications. 
> So there.
> ***************************************************************************
> Definitions:
> A "Package" refers to the collection of files distributed by the
> Copyright Holder, and derivatives of that collection of files created
> through textual modification, or segments thereof. 
> "Standard Version" refers to such a Package if it has not been modified,
> or has been modified in accordance with the wishes of the Copyright
> Holder.
> "Copyright Holder" is whoever is named in the copyright or copyrights
> for the package.
> "You" is you, if you're thinking about copying or distributing this
> Package.
> "Reasonable copying fee" is whatever you can justify on the basis of
> media cost, duplication charges, time of people involved, and so on.
> (You will not be required to justify it to the Copyright Holder, but
> only to the computing community at large as a market that must bear the
> fee.)
> "Freely Available" means that no fee is charged for the item itself,
> though there may be fees involved in handling the item.  It also means
> that recipients of the item may redistribute it under the same
> conditions they received it.
> 1.  You may make and give away verbatim copies of the source form of the
> Standard Version of this Package without restriction, provided that you
> duplicate all of the original copyright notices and associated
> disclaimers.
> 2.  You may apply bug fixes, portability fixes and other modifications
> derived from the Public Domain or from the Copyright Holder.  A Package
> modified in such a way shall still be considered the Standard Version.
> 3.  You may otherwise modify your copy of this Package in any way,
> provided that you insert a prominent notice in each changed file stating
> how and when AND WHY you changed that file, and provided that you do at
> least ONE of the following:
> a) place your modifications in the Public Domain or otherwise make them
> Freely Available, such as by posting said modifications to Usenet or an
> equivalent medium, or placing the modifications on a major archive site
> such as uunet.uu.net, or by allowing the Copyright Holder to include
> your modifications in the Standard Version of the Package.

This is not compatible with the GPL, which only requires that the source
be provided to others you distribute your binaries to.

> b) use the modified Package only within your corporation or organization.
> c) rename any non-standard executables so the names do not conflict with
> standard executables, which must also be provided, and provide separate
> documentation for each non-standard executable that clearly documents
> how it differs from the Standard Version.
> d) make other distribution arrangements with the Copyright Holder.

We should contact the original copyright holder, and ask if re-licensing
is possible.

> 4.  You may distribute the programs of this Package in object code or
> executable form, provided that you do at least ONE of the following:
> a) distribute a Standard Version of the executables and library files,
> together with instructions (in the manual page or equivalent) on where
> to get the Standard Version.
> b) accompany the distribution with the machine-readable source of the
> Package with your modifications.
> c) accompany any non-standard executables with their corresponding
> Standard Version executables, giving the non-standard executables
> non-standard names, and clearly documenting the differences in manual
> pages (or equivalent), together with instructions on where to get the
> Standard Version.
> d) make other distribution arrangements with the Copyright Holder.
> 5.  You may charge a reasonable copying fee for any distribution of this
> Package.  You may charge any fee you choose for support of this Package. 
> distribute this Package in aggregate with other (possibly commercial)
> programs as part of a larger (possibly commercial) software distribution
> provided that YOU DO NOT ADVERTISE this package as a product of your
> own. 
> 6.  The name of the Copyright Holder may not be used to endorse or
> promote products derived from this software without specific prior
> written permission.
> 				The End
Andrew Bartlett                                 abartlet at pcug.org.au
Manager, Authentication Subsystems, Samba Team  abartlet at samba.org
Student Network Administrator, Hawker College   abartlet at hawkerc.net
http://samba.org     http://build.samba.org     http://hawkerc.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.samba.org/archive/samba-technical/attachments/20030118/44d35134/attachment.bin

More information about the samba-technical mailing list