On Mon, Sep 26, 2005 at 03:37:15PM -0400, John Peacock wrote:
Actually, this level of paranoia is not useful, since it will fail to correctly operate in the very real case of co-hosted boxes.
I realize that. However I am assuming that this will not be the case of most clients. I would expect that in such a case, Dovecot would would simply pass the IP address as a string.
There can only be (in practice) a single mapping from IP => hostname (via in-addr.arpa),
Are you sure of that? I cannot say now for sure and do not have the the relevant RFCs at hand, but I had the impression that a DNS key may have more than one record of the same type and class, no matter what the type and class (of course this is not always feasible and may be limited somewhere else).
but there can be virtually limitless hostname => IP maps.
Right.
There were a few SMTP servers which supported "round-trip DNS checks" but by now, hopefully, the sysadmins running those boxes have been killed off by the userbase eager to actually receive e-mail.
Of course it may be that the forward and reverse lookup do not match, and I did not intend to just kick out such clients. My intention was to assume that in our network, forward and reverse lookups do match, and therefore a client where it does not match may be safely treated as not in our network (and even if that is not the real case, the most damage done by this would be someone having to authenticate against a stronger mechanism - he would still be able to use the service)
If PAM authentication supports different schemes based on source IP address, that is the best you can hope for.
PAM itself (libpam), of course, knows nothing about clients, servers, and networks. The authentication is done by application and PAM can not know where the application received the authentication data from, except for what the application passes the module as a parameter.
I do not recall there being a PAM item for IP address, but just for the remote hostname - rhost, which may be any string received by the application, and is only by convention expected to be the address of the client.
The only trustworthy value in a point-to-point TCP connection is IP (since it is impossible to spoof that due to the need to be able to get the response packets back later).
I realize that. However if all I (the module) get from Dovecot is the hostname, there is no way to know what the IP address of the client was. Actually, I anyway intend to do the classification by IP address and netmask - but the only sure way I had in mind, to get the IP address of the client from Dovecot is get the hostname and do a lookup on that, which is not reliable if Dovecot has not first checked that it really resolves to the same IP address.
Well, tomorrow I'll look into the sources and see if there is a way to get the IP address from Dovecot as a PAM module. If not, I may just write a patch for that (will probably make it configurable in dovecot.conf whether the PAM rhost item passed will be a hostname or IP address).
John
Cheers, -- Tom
-- Tom Alsberg - hacker (being the best description fitting this space) Web page: http://www.cs.huji.ac.il/~alsbergt/ DISCLAIMER: The above message does not even necessarily represent what my fingers have typed on the keyboard, save anything further.