My situation:
I obtained the npasswd code that allows me to enforce stricter
passwords than the sun supplied passwd program.
I am using NIS for my passwd file update with rpc.yppasswdd.
I installed the npasswd program on my systems and removed the
sun supplied passwd and yppasswd from all machines.
Note on npasswd: this program is available from ftp and incorporates
the update of the local passwd file or NIS map via rpc.yppasswdd in
the same program.
This all seemed to work fine until I started running a passwd cracking
program to check for simple passwords. Since I had expired all passwords
I expected to not find any if the new npasswd was working properly.
I did find passwords not conforming to the stricter rules. Thru a series
of events I learned that some users had copied the sun supplied passwd
program from a distribution tape into their account.
The sun supplied program will call rpc.yppasswdd to update a passwd
not located in the local /etc/passwd file. There is no protection
to determine anything about the calling program from inside
rpc.yppasswdd. And no requirement to run passwd as setuid root.
Thus there is nothing to stop a user from obtaining npasswd and modifying
it to allow any passwd.
Conclusion:
If a site administrator hopes to have any controll over the quality
of passwords then NIS password map updates using rpc.yppasswdd
cannot be allowed. The users must login to the host with the
/etc/passwd file to change passwords. This is easily accomplised
by making /usr/bin/passwd a shell script that will log the
user to the master passwd machine and execute passwd from there.
The task of redistributing the passwd data to the NIS servers must
be accomplished. Probably by a cron task. This creates a delay in the
user seeing the new passwd. A situation that has created numerous
inquiries from my users.
Malcolm Strickland chucks@iplmail.orl.mmc.com
Martin Marietta Electronic Systems 407-356-5909
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:06:14 CDT