password quality script aka --with-cracklib replacement

Pierre Belanger pbelang1 at oss.cantel.rogers.com
Thu Feb 13 18:05:17 GMT 2003


Hi,

I started this mail yesterday ... 24h/day is not enough since
the past few days :(

First of all, I forget to state in the documentation that the external
program also needs to send a ".\n" on a new line after sending the
"required" fields.


1) "Don't use recent password" feature:

I did not want to focuss on this feature yet but since it came
up on the list, lets do it ;-) This was actually the next thing
I thought of doing in terms on contribution to Samba!!!

a) If we want the password-quality script to handle this,
    I think we'll all agree, storing clear text password is really
    not a good idea. Perhaps the interface should provide the new
    encrypted passwords to the external program -- if administrators
    don't have "easy access" to the encrypted password, some will
    probably endup use the cleartext one :(
b) My idea was to incorporate this directly within smbd creating a
    database, tdb? but I have no clue on the specifications of tdb
    database -- perhaps I'm writing something really stupid  here :)
    If it's not possible with tdb, I guess we could use something
    else. I would be much better, in term of security, to store the
    old passwords using MD5 or even Blowfish (is it legal to
    distribute such encryption mechanism in Samba -- I'm thinking
    of the US encryption law restricting exportation).
    Any experts around?

I also think that such of "module" requires to remove all data
from the "old password database" when a user is deleted. Or we
provide a tool for systems administrators that checks if there
is still a match between what's in the "old pw db" and the
"pdb" / smbpasswd file, etc!?! If you have a clue now on how
to achieve this, great -- otherwise we'll think of this when
we get there!


2) PAM module

I'll leave this to someone else. I really think PAM rocks but
if we want to support this new feature on every supported OS
by Samba, I think we should not go PAM. Is PAM standard on
all Unix flavors? Will Windows ever support PAM? (Ain't someone
in this world trying to port Samba to Windows? -- I wouldn't be
surprised, LOL).

Ain't people moving towards pdb LDAP backend using the included
LDAP support in Samba instead of using PAM?


3) "Failed" script

Yes, if the script fails to run or return an exit status != 0,
smbd deny the change request.


4) Root / non-root

We could add an attribute "password quality runas root (true/false)"
in smb.conf .   Should we?


5) "Protocol"

Do we agree on the following for "version: 1\n"?

- Version starts @ 1
- Space added ... "Field: value\n" -- External can return
   with or without a space. I think on the answer we can be
   a little bit "flexible", is that fine?
- Send empty string value if a "value" is not available:
   "Fullname: \n"
- I agree with Andrew -- "string protocol is much easier to
   implement / debug". I don't know how the fullname will be
   passed to the external if there are "funky" characters, I know
   this is not a problem with the other Fields. Perhaps for
   release #1 we don't send the "fullname"?

   If we need some type of "encoding / decoding" mechanism,
   shouldn't we use something already "very popular". If it's
   too complicated, people won't use it.

- Returned NTSTATUS. Allow both string and hex or not?

   The code presently does this: ... pnstatus is the "NTStatus"
   returned value. presult is the "Result" (debug info) returned
   value.

      /* Match returned NT status from external program */
      ntstatusmap = nt_status_string_to_code(pntstatus);

      if NT_STATUS_EQUAL(ntstatusmap, NT_STATUS_UNSUCCESSFUL) {
              DEBUG(1,("Undefined NTSTATUS %s received from %s\n",
                       pntstatus, cmdname));
              DEBUG(1,("user %s could not change password - %s\n",
                       username, presult));
              return NT_STATUS_ACCESS_DENIED;
      }

      if (!NT_STATUS_IS_OK(ntstatusmap)) {
              DEBUG(1,("user %s could not change password - %s\n",
                       username, presult));
              return ntstatusmap;
      }

      return NT_STATUS_ACCESS_DENIED;

   If tomorrow there is a new "return code" available, it will work
   once it is added in "nterr.h".

   When I first wrote the documentation I wrote something like:
   "we suggest that you use one of the following NTSTATUS for this
   context" but I figured perhaps the protocol should not be
   flexible. Either when there's a new NTSTATUS for this context,
   we had it in "nterr.h" and password-quality.c  OR we leave it
   like it is now, i.e. accept anything defined in "nterr.h".

   Honestly, I'm still not sure if we should allow both. I know I don't
   really like the idea of smbd returning something not defined in
   "nterr.h".

   True "protocols" always use numeric values. "440 - File not found" !
   If we have to modify the source code when we need to add a new
   supported returned value, I think we'd rather just need to add this
   new "value" in nterr.h and Voila!

- Password field -- "injection attacks"

   No answer yet on the message (Password changing - root bug?) I sent
   yesterday night (today early AU time!!!) on the mailing-list. If
   control-chars are "illegal" , I'll check for this and return, I guess
   NT_STATUS_ILL_FORMED_PASSWORD would be appropriate here.


Thank you for your valuable comments. I look forwards to read yours.

Pierre B.



More information about the samba-technical mailing list