blacklistd support for dovecot
Greetings all!
I ported the NetBSD blacklistd support into FreeBSD a while ago (FreeBSD 11.x timeframe). I also added support to several of the system daemons there, so they could all talk to a centralized daemon (blacklistd).
One of the third party apps that I added support to was sendmail - that works pretty well.
So I'm now finally turning my attention adding blacklistd support to dovecot (which is the imap daemon that I use).
I did an implementation to an earlier version, and that worked OK, at least for non-encrypted access to the imap server. However, the encrypted access (TLS) doesn't work right.
To authenticate a network connection, the daemon must pass the fd of the remote connection over a unix domain socket to the actual blacklistd daemon. The blacklistd daemon will then call getpeername() on the connection, so it can determine the remote connection endpoint, rather than just having to believe some made-up set of data that is passed to it from process on the local machine.
Christos Zoulas' talk on blacklistd is here: https://www.youtube.com/watch?v=fuuf8G28mjs
Anyhow -- the problem I've run into is that there doesn't seem to be any way to get access to the fd of the socket that holds the raw connection to the client when TLS encryption is active. It looks like the only connection I get is to the proxy process.
Is there any guidance that someone can give with how to implement this?
Thank you.
-Kurt
On 20.09.2018 00:48, Kurt Lidl wrote:
Greetings all!
I ported the NetBSD blacklistd support into FreeBSD a while ago (FreeBSD 11.x timeframe). I also added support to several of the system daemons there, so they could all talk to a centralized daemon (blacklistd).
One of the third party apps that I added support to was sendmail - that works pretty well.
So I'm now finally turning my attention adding blacklistd support to dovecot (which is the imap daemon that I use).
I did an implementation to an earlier version, and that worked OK, at least for non-encrypted access to the imap server. However, the encrypted access (TLS) doesn't work right.
To authenticate a network connection, the daemon must pass the fd of the remote connection over a unix domain socket to the actual blacklistd daemon. The blacklistd daemon will then call getpeername() on the connection, so it can determine the remote connection endpoint, rather than just having to believe some made-up set of data that is passed to it from process on the local machine.
Christos Zoulas' talk on blacklistd is here: https://www.youtube.com/watch?v=fuuf8G28mjs
Anyhow -- the problem I've run into is that there doesn't seem to be any way to get access to the fd of the socket that holds the raw connection to the client when TLS encryption is active. It looks like the only connection I get is to the proxy process.
Is there any guidance that someone can give with how to implement this?
Thank you.
-Kurt
Hi!
Dovecot retains the fd for *-login process due to SSL not being such easy to move between processes. If you want to add blacklistd support, you'd have to patch the login process to send the original fd to blacklistd and check result.
Aki
participants (2)
-
Aki Tuomi
-
Kurt Lidl