This patch allows the dovecot proxy processes to lookup the destination
host by name instead of IP address. Tested agains 1.2.10, expected to
work against 1.2.11.
The patch is pretty straightforward, it's making it work within the
restrictions of the login process that's more interesting.
I have made some changes to the wiki (pending approval) to
- enhance the discussion of proxy with LDAP
http://wiki.dovecot.org/PasswordDatabase/ExtraFields/Proxy
- discuss the implication of this patch w.r.t. the login_chroot
configuration parameter:
http://wiki.dovecot.org/PasswordDatabase/ExtraFields/Proxy/HostLookup
Feedback is appreciated, particulary from a security standpoint.
Cheers,
-Martin Foster
martin_fos...@netlog.net
dump of wiki info, for the lazy. It will look better if viewed from the
URL:
http://wiki.dovecot.org/PasswordDatabase/ExtraFields/Proxy/HostLookup
For all released versions of Dovecot, the "host" referred to in a
proxy or proxy_maybe lookup must be an IP address
see: the main PasswordDatabase/ExtraFields/Proxy
<http://wiki.dovecot.org/PasswordDatabase/ExtraFields/Proxy> page for
more info
A patch is available to enable lookups, but it has some imporant caveats
due to the nature of the LoginProcess
<http://wiki.dovecot.org/LoginProcess> that the proxy function is a part
of. This page exists to discuss these.
The Problem
Proxying is done from the dovecot login processes, both pop3-login &
imap-login call code in src/login-common/login-proxy.c to handle the
proxying to the given host.
If the host is not an IP address, name resolution must be done. Two
options from dovecot's configuration:
1. Dovecot running with roots
Dovecot is started as root and drops privileges later; this is the
recommended way of running Dovecot. Set by the config option:
login_chroot = yes.
In this mode, the login process is chrooted to login_dir, from which the
proposed patch adds name resolution. Resolution is done via dovecot's
net_gethostbyname() function - a wrapper for getaddrinfo/gethostbyname
depending on compile-time platform support.
These functions need access to the name service switch configuration,
then whatever dependencies are required to consult the host resolution
databases stipulated.
so, if the /etc/nsswitch.conf hosts entry is:
hosts: dns files
Then the system will need access to /etc/resolv.conf and the nss_dns
libraries for "dns" lookup, and /etc/hosts for "files" lookup.
The exact files will vary by platform/operating system, but these all
need to be available in the chroot for the lookup to succeed.
and, if dovecot.conf has:
login_chroot = yes
login_dir = /var/run/dovecot/login
login_user = dovecotuser
Then for the nsswitch.conf entry above, the following files need to be
copied (not symbolically linked!) to the chroot. This example is for a
64-bit RHEL5 system, with 64-bit dovecot daemon. Ownership of the new
directories must be set to whatever the login_user is set to.
mkdir /var/run/dovecot/login/etc
mkdir /var/run/dovecot/login/lib64
cp /etc/nsswitch.conf /etc/resolv.conf /etc/hosts /var/run/dovecot/login/etc
cp /lib64/libnss_dns.so.2 /var/run/dovecot/login/lib64
chown -R dovecotuser:dovecotuser /var/run/dovecot/login/etc
chown -R dovecotuser:dovecotuser /var/run/dovecot/login/lib64
Remember that the ownership of the login_dir itself *must not* be
changed. So:
# ls -ld /var/run/dovecot/login/
drwxr-x--- 4 root dovecotuser 4096 Mar 12 06:48 /var/run/dovecot/login/
Troubleshooting
If the lookup fails because of a perceived lookup-in-chroot issue, an
error message of this form will be printed to the logs
dovecot: pop3-login: proxy(t...@domain1.test): cannot resolve
mailhost.domain1.test. If name resolution is working outside dovecot, it may be a
chroot issue. See LoginProcess on wiki, and login_dir& login_chroot in config.
Clients will receive a much less descript general error message, for
example with POP3:
-ERR [IN-USE] Account is temporarily unavailable.
Things to check
1. does name resolution work for normal users? the dovecot user?
2. are all the files required by the Name Service Switch's
configuration available? Use a process tracing tool such as strace
or truss against the pop3-login or imap-login processes to check.
3. are other security measures interfering? eg:
1.
SELinux
<http://en.wikipedia.org/wiki/Security-Enhanced_Linux>
(RedHat <http://www.redhat.com/rhel/> EL, CentOS, Oracle EL)
2.
AppArmor <http://en.wikipedia.org/wiki/AppArmor> (SuSE,
Ubuntu?)
3.
RBAC (Solaris, OpenSolaris
<http://en.wikipedia.org/wiki/Open_Solaris>)
Caveats
This procedure allows the chroot'ed login to do something, which forms a
security risk if the libraries in the chroot are exploitable.
It will be up to the operator to ensure that the copy of the files in
the chroot get updated whenver the copies in the real filesystem do. On
systems where the chroot is on the same filesystem/partition that the
original file copies are, hard links (again: no soft links!) could be
used to accomplish this.
2. Dovecot running without roots (RootLess)
Dovecot is started as whatever user/group is used to start the master
daemon. See the discussion on Rootless
<http://wiki.dovecot.org/HowTo/Rootless> for reasons why this is not the
recommended way of running Dovecot, which includes a discussion on how
this is more likely to be less secure.
In dovecot.conf, rootless is selected by setting:
login_chroot = no
In this mode, the login process will have access to the required Name
Service Switch configuration files and their dependencies if the user
that started dovecot did.
No further configuration is required for the proxy process to lookup
hostnames.
--- ORIG/dovecot-1.2.10/src/login-common/login-proxy.c 2010-01-24
23:14:17.000000000 +0000
+++ dovecot-1.2.10/src/login-common/login-proxy.c 2010-03-12
04:45:29.000000000 +0000
@@ -194,18 +194,36 @@
{
struct login_proxy *proxy;
struct login_proxy_record *rec;
- struct ip_addr ip;
- int fd;
+ struct ip_addr ip, *ip_list;
+ char *host_ip;
+ int fd, ret;
+ unsigned int ip_count;
if (host == NULL) {
i_error("proxy(%s): host not given", client->virtual_user);
return NULL;
}
- if (net_addr2ip(host, &ip) < 0) {
- i_error("proxy(%s): %s is not a valid IP",
+ host_ip = t_strdup(host);
+ ret = net_gethostbyname(host, &ip_list, &ip_count);
+ if (ret != 0) {
+ i_error("proxy(%s): cannot resolve %s. "
+ "If name resolution is working outside dovecot, it may
be a chroot issue. "
+ "See LoginProcess on wiki, and login_dir & login_chroot
in config.",
+ client->virtual_user, host);
+ return NULL;
+ } else if (ip_count < 1) {
+ i_error("proxy(%s): succesfully resolved host %s, got no IPs.",
client->virtual_user, host);
return NULL;
+ } else {
+ host_ip = t_strdup(net_ip2addr(&ip_list[0]));
+ }
+
+ if (net_addr2ip(host_ip, &ip) < 0) {
+ i_error("proxy(%s): %s is not a valid IP",
+ client->virtual_user, host_ip);
+ return NULL;
}
rec = login_proxy_state_get(proxy_state, &ip, port);
@@ -218,13 +236,13 @@
fd = net_connect_ip(&ip, port, NULL);
if (fd < 0) {
i_error("proxy(%s): connect(%s, %u) failed: %m",
- client->virtual_user, host, port);
+ client->virtual_user, host_ip, port);
return NULL;
}
proxy = i_new(struct login_proxy, 1);
proxy->created = ioloop_timeval;
- proxy->host = i_strdup(host);
+ proxy->host = i_strdup(host_ip);
proxy->user = i_strdup(client->virtual_user);
proxy->port = port;
proxy->ssl_flags = ssl_flags;
