[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Help needed on custom Solaris 7 PAM modules



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






[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index] []