On Sun, Dec 21, 2003 at 10:58:20AM +1000, Andy Gayton wrote: > I was hoping to use pam to set up a second password file and to change the > sshd and checkpassword-pam (for bincimap) authentication configs to > something like: > > * authenticate with control-flag sufficient off the second less secure > password file - if authenticate is ok hardcode the shell so it can only > ever possibly be /usr/local/sbin/scponlyc and the home directory so it can > only possibly be /wwwusers/<username>//incoming - the '//' part will cause > scponly to chroot the user to /wwwusers/<username> > * authenticate with control-flag required - use the usual sshd and > checkpassword-pam configs which work off the system passwd files .. Or how about: auth sufficient pam_pwdb.so auth required pam_chroot.so chroot_dir=/wwwusers auth required pam_pwdfile.so pwdfile /etc/whatever ... Note that the file which pam_pwdfile.so would actually be accessing is /wwwusers/etc/whatever and also that unless pam_pwdb.so caches, you should be able to just use a second call to pam_pwdb.so instead of pam_pwdfile.so if you use /etc/passwd instead of /etc/whatever By using a chroot() earlier (during auth) rather than later (during session,) you can trick all your daemons into thinking they're reading the standard passwd file. This is still pretty scary, though, since a compromised httpd user could still put an entry in the secondary passwd file for a uid 0 user, and once you're root you can break out of the chroot pretty easily. If I were you, I would NOT allow httpd to modify a file that gives authentication information to root-owned processes (such as sshd.) Instead, put that functionality into a daemon that reads from a command file (written to by the httpd processes) and does sanity checking. As a bonus, you get to completely eliminate that secondary passwd file by doing it this way. -- Ed Schmollinger - schmolli@xxxxxxxxxxxxxx
Attachment:
pgp00128.pgp
Description: PGP signature
