> i thought about this one this weekend, if /bin/false is in /etc/shells
> and you have ftp enabled, then a user could ftp in a .qmail file that
> contains a expect script that runs chsh, and boom, they have a shell. how
> to avoid this, options:
/bin/false should never be in /etc/shells, period.
If one wanted to be paranoid about it, one could specify different passwords
for login vs. POP access by using a custom checkpassword with qmail-pop3d.
One could authenticate against a database, or perhaps against a Kerberos
server with the principal user.pop@domain (which would have a different
password than the principal user@domain).
One could also use the Cyrus IMAP/POP server which has the additional
advantage that one doesn't need users in /etc/passwd to begin with (as long
as one authenticates against Kerberos, or one writes a custom pwcheck daemon
to authenticate against something other than /etc/passwd). Cyrus can also
support Kerberised POP if the MUA supports it (ie: Eudora) which means
encrypted POP sessions.
Finally, assuming all customers use MUAs that support SSL (ie: Communicator
and Outlook Express) one could wrap the POP server with stunnel and do
encrypted POP sessions.
I described how to get Cyrus' deliver to cooperate with qmail and how to
wrap qmail-pop3d with stunnel a few months ago; one should be able to find
those messages quite easily in the list archives.
Evan
