[Dovecot] Configure dovecot to provide SASL authentication
Hi, I'm trying to get dovecot to provide SASL authentication for postfix My setup appears to be working but I'm not 100% certain I've got it right. I've come across several examples for dovecot version 1 but I'm running 2.0.9. The output of doveconf -n is here :
2.0.9: /etc/dovecot/dovecot.conf # OS: Linux 2.6.32-279.2.1.el6.x86_64 x86_64 CentOS release 6.3 (Final) auth_debug = yes auth_verbose = yes disable_plaintext_auth = no mbox_write_locks = fcntl passdb { driver = pam } protocols = imap service auth { unix_listener /var/spool/postfix/private/auth { mode = 0666 } } ssl_cert =
Specifically : are the "service auth", userdb and passdb sections correct ? And the mode ? Or is it too permissive ?
For completeness the postfix setup is here :
smtpd_sasl_auth_enable = yes broken_sasl_auth_clients = yes smtpd_sasl_type = dovecot smtpd_sasl_path = private/auth smtpd_sasl_security_options = noanonymous # smtpd_delay_reject = yes smtpd_helo_required = yes smtpd_helo_restrictions = permit_mynetworks, reject_non_fqdn_helo_hostname, reject_invalid_helo_hostname, permit # smtpd_sender_restrictions = permit_mynetworks, reject_non_fqdn_sender, reject_unknown_sender_domain, permit # smtpd_recipient_restrictions = reject_unauth_pipelining, reject_non_fqdn_recipient, reject_unknown_recipient_domain, permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination, permit #
peter
Peter Skensved Dept. of Physics, Queen's University, Kingston, Ontario, Canada
At 6PM +0200 on 19/05/13 you (Reindl Harald) wrote:
Am 19.05.2013 17:51, schrieb Peter Skensved:
service auth { unix_listener /var/spool/postfix/private/auth { mode = 0666 }
chmod 666 is always a very bad idea
While I would agree with you in principle, the documentation (http://wiki2.dovecot.org/Services#auth) actually says
client: Only SASL authentication is allowed. This can be safely
exposed to entire world.
Given that the SASL auth service will eventually be exposed to untrusted users via SMTP, the only additional risk from making this socket world-readable is that (AFAIK, at least) there is no rate-limiting. This makes the socket a password oracle, which can by used be any local user with access to the socket to mount a dictionary attack.
However, given again that the permissions on /var/spool/postfix/private should be 0700 postfix:wheel, and that (again AFAIK) all modern systems check the permissions on the full path when connecting to a Unix-domain socket, it doesn't actually matter what the permissions on the socket are as long as postfix can connect, so 0666 is in this case entirely safe.
Ben
participants (3)
-
Ben Morrow
-
Peter Skensved
-
Reindl Harald