On Wed, 2003-02-12 at 15:50, Martin Pool wrote: > On 11 Feb 2003, Pierre Belanger <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] Manager, Authentication Subsystems, Samba Team [EMAIL PROTECTED] Student Network Administrator, Hawker College [EMAIL PROTECTED] http://samba.org http://build.samba.org http://hawkerc.net
signature.asc
Description: This is a digitally signed message part