21.12.2024 16:16, Viktor Dukhovni via Postfix-users wrote:
On Sat, Dec 21, 2024 at 01:51:46PM +0300, Michael Tokarev via Postfix-users
wrote:
...
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 cleartext
password storage required.
cleartext password (storage) is required for many SASL mechanisms over
than PLAIN. And none of these mechanisms work with -a pam or with
saslauthd to begin with. And people do use them, or at least do ask
about them. I haven't used SASL before today and learning it as we
speak, -- I don't know which mechanisms are actually useful or not.
What you're suggesting is to stick with PLAIN when Cyrus SASL is concerned.
However, there are other mechanisms being developed, for example OAUTH2,
which, in terms of Cyrus SASL, does not work with saslauthd at all, so
needs direct integration within postfix in a form of plugin. Should such
mechanisms be avoided in Postfix?
[...] 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"...
Aha. Thank you for this. I suspected it's the case - while looking
at the code and searching the 'net.
...
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.
So basically, can we forget that SASL security layers exists?
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.
As I already mentioned, people do use other SASL mechanisms with Cyrus
SASL configuration (since dovecot sasl is an integral part of dovecot,
and not everyone uses dovecot). And for these to work, the code has to
be run directly by postfix components, in a form of plugins, because
saslauthd does not implement anything but PLAIN/LOGIN. This is exactly
the place where it *looks* like postfix needs a proxy of some sort.
Saslauthd already does what's needed for PLAIN/LOGIN, but other mechanisms
doesn't work with it.
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.
Unix socket path is not a problem, it's easy to specify in configuration
and there's no proxying needed for that (well, besides saslauthd supporting
just a single socket, but that's a different issue which is solved by other
means).
... But we've mentioned a number of times already, that chroot is
simply not a good choice for a distro to support.
I still yet to see the reason for this, besides a statement "chroot is
painless for freebsd but for linux is unsupportable", which is nothing
but a big old myth, since the two works the same.
Here, there's no issue in supporting additional postfix-accessible sockets -
be it in chroot or not, it doesn't really matter. But there IS a problem
supporting additional SASL mechanisms which require access to the secrets
storage, - not from the chroot PoV but from general security PoV. And these
additional SASL mechanisms can not be implemented using saslauthd.
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.
So, are we limited by saslauthd+PLAIN (no other mechanisms), or dovecot with
anything? In other words, postfix works with dovecot SASL only, and has
very limited support for Cyrus SASL?
I'm not sure I understand the "LDAP service as a password oracle" choice, -
who does the SASL verification in there?
Thank you for the reply!
/mjt
_______________________________________________
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
