dovecot - Sep 2018 - 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