On Sat, Dec 21, 2024 at 01:51:46PM +0300, Michael Tokarev via Postfix-users
wrote:
> Hi!
>
> I'm trying to get a "big picture" about how postfix works with
> various SASL options. It looks like there's a big overview
> missing in the docs somehow.
>
> We've basically two big kinds of SASL mechanisms: plaintext
> (which are login and plain) and non-plaintest (everything else).
> The "everything else" requires custom storage for secrets, be
> it plaintext passwords storage or some mechanism-specific
> format.
Well, GSSAPI requires an "smtp" keytab, but no per-user secrets for the
Postfix administrator to manage, that's taken care of by the operator of
the KDC, independently of Postfix concerns (perhaps the same operator,
but nothing Postfix-specific about managing user Kerberos principals).
> As far as I can see, Cyrus SASL can work with plaintext methods
> using saslauthd (which has very simple username,password => ok|bad
> protocol), and can use any mechanism when having accesses to
> secrets storage directly from an application (postfix in our
> case).
Or use "-a pam", and then whatever backend PAM supports, so no cleartex
password storage required.
> There's nothing in the docs saying if dovecot sasl can work with
> non-plaintext mechanisms.
What dovecot supports is described in dovecot docs. I'm in fact
using the dovecot GSSAPI backend:
auth_realms = ...
auth_mechanisms = gssapi plain
auth_gssapi_hostname = "$ALL"
auth_krb5_keytab = /var/spool/keytabs/imap
> In almost all docs and examples I've
> found, dovecot side of the config is configured with
> "auth_mechanisms = plain login". There are some vague references
> to usage of other mechanisms, for example
>
>
> https://serverfault.com/questions/713442/postfix-dovecot-with-mysql-backend-md5-hashed-passwords-and-cram-md5-auth
>
> but these are rare, usually very old, and inconclusive. So the
> question is whenever non-plaintext mechanisms are actually
> supported with dovecot sasl type.
Definitely, but a matter for Dovecot documentation, much more than
Postfix. If dovecot supports mechanism "X", then Postfix with
dovecot as a SASL backend supports mechanism "X", and all the
configuration for that is on the "dovecot" side, with the
service name however "smtp", rather than "imap", so the GSSAPI
keytab file needs to contain keys for a service principle with
"smtp" as the service name and the MX hostname (as known to the client)
as the instance component. In addition to any similar principals
for IMAP, ...
# ktutil -k /var/spool/keytabs/imap list
/var/spool/keytabs/imap:
Vno Type Principal Aliases
2 aes128-cts-hmac-sha1-96 imap/<imap-hostname>@SOME.REALM
2 aes128-cts-hmac-sha1-96 smtp/<submission-hostname>@SOME.REALM
> And finally, some SASL mechanisms also provides encryption, like an
> alternative to TLS. Am I right this is not implemented in Postfix?
Indeed SASL security layers are quite obsolete, and basically never
used, though in principle they achieve channel binding, which is
typically absent with SASL inside TLS.
> This SASL thing turned out to be quite complex due to various
> possibilities and restrictions (so much for "simple").
Well, simpler than directly implementing all the various mechanisms in
the SASL-using application.
> Now, there's another aspect: accessing SASL data/sockets from Postfix.
> And in this context, there are really awful suggestions which are
> repeated in multiple places, especially when postfix is configured to
> run chrooted - like suggestions to move /etc/sasldb2 to
> /var/spool/postfix/ and made it rw to postfix:postfix - this feels
> insane. Adding there various libraries and config files for cyrus
> sasl plugins and other "interesting" stuff..
In almost all cases access to secrets should be proxied, via dovecot or
saslauthd. Configurations in which the SASL library directly accesses
shared secrets should be strongly discouraged. There are thing like
using LDAP "bind" as a password oracle, which are tricky to set up and
brittle, but ok'ish if done over (server by client) authenticated TLS.
> It *feels* like Postfix needs some separation of this sasl stuff into
> its own process somehow, similar to how proxymap is done, so that
> eg cyrus sasl code is not linked directly into smtp[d] with all its
> large code.
No, rather one should avoid mechanisms that don't already do that, where
adding yet another proxy doesn't help much. The only thin then that a
proxy does is perhaps help a bit with unix-domain socket paths vs.
chroot. But we've mentioned a number of times already, that chroot is
simply not a good choice for a distro to support.
> If we don't use sasl-based session encryption, it should be relatively
> easy. This daemon can have its own privileges which allows it to work
> with secrets database without granting access to it to whole postfix.
No, far better to NOT have any secrets databases, that aren't already
part of a suitable system service:
- saslauthd proxying PAM
- dovecot auth with whatever backends it supports
- a Kerbers KDC
- an LDAP service as a password oracle (Active Directory
might then actually do Kerberos behind the scenes, but
that's its business).
Basically, avoid all temptation to manage/access individual user
credentials directly in Postfix.
--
Viktor.
_______________________________________________
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
