password quality script aka --with-cracklib replacement
Andrew Bartlett
abartlet at samba.org
Wed Feb 12 07:39:33 GMT 2003
On Wed, 2003-02-12 at 15:50, Martin Pool wrote:
> On 11 Feb 2003, Pierre Belanger <belanger at pobox.com> wrote:
>
> > What is it? I have my own comments at the end ...
> >
> > From the documentation I wrote (even if I'm French I think it's not
> > that bad!?!?!?):
>
> This looks good to me.
>
> Would it be possible to do this as a PAM module called by Samba?
> (Possibly not, or not appropriate, but I thought I'd ask.)
Because we don't have the old password, doing this via PAM doesn't
work. The pam_cracklib module doesn't apply the test if it's run as
root, and won't run without the old password as a normal user.
> Presumably if the script is set in the smb.conf but can't be run then
> Samba ought to "fail closed" and deny the change request.
That certainly sounds reasonable.
> Is there any need to allow changes by the administrator to bypass this
> check?
Administrative password changes should not be affected - they use a
different code-path.
> > Full path to the script that will be called when a
> > request for change password is received. It will be run
> > by smbd as non-ROOT.
> >
> > The script is responsible to accept or refuse the new
> > password based on its own rules. As an example, it can
> > be a script refusing a weak password based on a dic-
> > tionary word.
>
> OK, that sounds good.
>
> For things like preventing password reuse the script will need to keep
> a database of (probably hashed) old passwords. It's probably best to
> keep this functionality out of smbd.
This interface really could do this rather well - I had not thought of
that side of things. This is one of the few things that has been pushed
as 'enterprise required' (read: Corporate bureaucracy required).
> Are there permissions problems in the script maintaining state such as
> this? The interface ought to define whether the script will be run
> under the uid of the person whose password is being changed. Perhaps
> some scripts will need to be setgid to store information in a file not
> accessible to the user -- after all the point of this is to impose
> restrictions on what the user can do.
>
> In fact, it seems to me that to be really secure, this operation *must
> not* be done under the uid whose password is being changed: enforcing
> security from a process under the control of that user is very weak.
Given the storage of old passwords as a quite a likely use of this
script, I think running as root is probably the best idea. Paranoid
scripts can certainly change to another uid if they feel the need.
> > Samba back end communicates with the password quality
> > program by writing data to its STDIN and reading data
> > from its STDOUT. Samba writes a block of data in
> > "Field:value\n" terminated by a ".\n" at the beginning
> > of a new line.
> >
> > 1) smbd to ---> Password quality script "STDIN"
> >
> > Version:smbd-version-string\n
> > Username:username\n
> > Fullname:fullname\n
> > Password:new-password\n
> > .\n
>
> This seems conceptually good, but I have a few comments on the format.
>
> The interface definition ought to say that the strings are sent in
> UTF-8.
>
> Using \n for a delimiter seems like asking for trouble; such as a
> fullname or new password containing that character. I'd suggest \0.
> I don't think this has to be a human-readable protocol.
The advantage of human-readable is testing. Being able to debug such a
script at the command line really is helpful - but we certainly must
ensure we avoid injection attacks.
> I am not sure that the "headings" like "Version:" really add much. If
> you're going to use something like RFC822 then it ought to be a closer
> match, with a space after the colon. Similarly, rather than the final
> dot, why not close the connection?
>
> Perhaps it would be better to specify the "protocol version", rather
> than the smbd version? i.e. just send "Version: 1" at first. A
> script written today doesn't know what future version numbers will be.
This is certainly a must.
> Personally I would use something like a tdbpacked string, which avoids
> worries about strange characters or string parsing, and is easy to
> handle in C, Perl, and Python.
This is an interesting idea - but how available is the interface for our
particular custom string format?
> > NTStatus:ntstatus-string\n
> > Result:result-string\n
> > .\n
> >
> > The "ntstatus-string" value must used one the pre-
> > defined NTSTATUS (nterr.h) values. In this context:
> >
> > NT_STATUS_OK # New password accepted
> >
> > NT_STATUS_ACCESS_DENIED # Error occured in the script
> >
> > NT_STATUS_PASSWORD_RESTRICTION # Too short, weak, etc.
>
> I think you should send the hex value, not the string.
I suggested the string - I don't think sending the hex value adds much,
and makes it less self-documenting. Parsing the string is trivial, as
we already have the lookup routines (I use it for a custom-hack auth
module). We could certainly allow both - which would allow a new
NTSTATUS code to be used in the unlikely event a useful one appears in
this context.
> > The "result-string" value is used to provide informa-
> > tion (debug info) to smbd. For examples:
> >
> > NTStatus:NT_STATUS_PASSWORD_RESTRICTION\n
> > Result:Password is based on dictionary word\n
> >
> > or
> >
> > NTStatus:NT_STATUS_OK\n
> > Result:New password is accepted\n
> >
> > smbd will always return an error to the client and does
> > not change the current password unless the NTStatus
> > value is equal to "NT_STATUS_OK" and the exit status of
> > the script equal to 0.
> >
> > Default: password quality script = <empty string>
> >
> > Example: password quality script =
> > /usr/local/samba/sbin/password-quality.pl
>
> > Do you wonder why sending the "smbd-version-string"? Perhaps
> > in the future a new NTSTATUS will be added. The only way for the
> > external program to know if it can use the new value is by
> > knowing the version of Samba! There are other possible examples.
>
> If you send the hex value, then it doesn't matter if Samba understands
> the code or not -- it can just pass it back to the client. Anyhow,
> I don't think it's likely that the script authors will know exactly
> which versions of smbd support which codes.
>
> > [Q] What do we do with the fullname? We don't care? What if it's not
> > available ('\0')? Do we write to the external program an empty string
> > like this ->Fullname:\n<- or we just don't send the fullname field
> > to the external program or perhaps something like "Fullname:Unknown\n"?
> > I think -- either we always send something (Unknown when it's empty)
> > or we just don't send it. I think it's less confusing for everyone
> > is we write in the documentation if fullname is not known, we write
> > "Unknown" (or empty or NULL!).
>
> Please don't send the string "Unknown"; that loses information. If
> it's null, just send an empty string.
>
> > Let me know what you think and/or other ideas.
>
> Hope that helps.
Thank-you both for your comments and code - I really think this will be
a powerful interface for Samba.
Andrew Bartlett
--
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/20030212/375a6457/attachment.bin
More information about the samba-technical
mailing list