Hello all, Sorry, this email is rather long and it is related to an earlier message that I posted a few days ago. This one is more precise I hope. I would like to hear your enlightened opinion on some issues raised with using custom PAM modules under Solaris 7. I have written a series of PAM modules to add S/Key to the standard Solaris PAM stack. The first one handles the S/Key auth part, strictly speaking, the second one handles the /etc/skey.access file (eg is S/key mandatory for this user coming from this IP ?) and the third one is an attempt at writting an appropriate account module. I use the following configuration : telnet auth sufficient /<path>/pam_my_skey.so telnet auth requisite /<path>/pam_my_skey_access.so telnet auth required /<path>/pam_unix.so.1 debug try_first_pass telnet account sufficient /<path>/pam_my_skey_acct.so telnet account required /<path>/pam_unix.so.1 debug --> Issue 1 When going through a successful auth phase using S/Key, the pam_sm_setcred() function of Sun's pam_unix.so is called, even though the pam_my_skey.so module is marked as sufficient, -ie- the pam_sm_authenticate() function of pam_unix.so has not (and won't be) called. I've found discussions about this behaviour in the archives of this list, but since I must use Solaris, I have to cope with its binary module. The only _obvious_ problem is that this pam_sm_setcred() call triggers the following syslog entry : Aug 22 15:30:42 <mymachine> login: pam_sm_setcred(): no module data So I examined Sun's pam_unix.so with strings and I found the string SUNW-UNIX-AUTH-DATA to be a good candidate for the ID of the expected data. So I added a pam_set_data() call to add a persistent pointer to a value of 1 with this ID. The syslog entry went away. Do you think this is an acceptable approach or an horrible hack ? Do I have a chance to break anything important security-wise (side effects inside pam_unix for example) if I do this trick ? --> Issue 2 My second question is about the account part of PAM. Since I try to add S/key to the system, fields in /etc/shadow that hold expiration or password information (say, "*LK*" for locked password) become less relevant with regard to the new authentication method. But those fields are checked by pam_unix and it may lead to a broken behaviour (for example, if my UNIX password has expired and I'm successfully authentified with S/Key then pam_unix tells me my UNIX password has expired and that I have to change it. I loose everything : I am asked to send cleartext passwords on the wire and I won't log in anyway). This is why I had to write a custom account module that doesn't enforce password expiration or locking. I had to set a persistent data with pam_set_data() (using my own ID, say DID-SKEY) inside pam_my_skey.c at the end of a successfulI authentication phase. This data tells pam_my_skey_acct.so that we went through S/key and that it should return so that it bypasses pam_unix.so (see my pam.conf configuration). Of course, if the DID-SKEY data is not there, return PAM_IGNORE so that we go on with the module stack. For now, the pam_my_skey_acct.so module only checks for the existence of the account to return PAM_SUCCESS. Obviously this is a lot less than the standard account checkings enforced by pam_unix, but I don't have the source, so I can't be sure. Do you think this is the right way to solve this problem ? Do you see any important actions that should be done by a properly written S/Key account module, apart from calling getpwnam() and getspnam() to validate the account ? Am I such a fool that I have crippled the security of my Solaris machine with those silly ideas ? I'd be really happy if you could have a look at my questions and share your opinion with me. I would also be very happy if someone would agree to review my code. These are security modules, I'd rather not rely on my only brain. Thanks in advance. Anyway, thank you for reading and have a nice day. -- David
