SASL, Debian, Chroot, and authentication

I'm trying to set up SASL so I can authenticate SMTP users against the
normal system accounts via PAM. I've read many docs on this, and I
can't get it to work with Debian (stable)'s package. The goal is to
let users who can authenticate with their normal username and password
to relay mail through the system regardless of where they are.

All I've been getting is library errors in the logs. By copying libraries into
the chroot jail, postfix stopped putting SASL authentication failed
messages in the logs. The daemon currently is working fine for
sending mail internally, and receiving mail (it's the primary MX for a
domain) the only problem is with SMTP authentication. My configuration:

# uname -a
Linux hostname.org 2.4.20 #3 SMP Fri Feb 7 14:00:08 EST 2003 i686 unknown
(Debian version 3.0 Packages)
ii libc6 2.2.5-11.2 GNU C Library: Shared libraries and Timezone
ii postfix 1.1.11-0.woody A high-performance mail transport agent
ii postfix-doc 1.1.11-0.woody Postfix documentation
ii postfix-ldap 1.1.11-0.woody LDAP map support for Postfix
ii postfix-pcre 1.1.11-0.woody PCRE map support for Postfix
ii postfix-tls 1.1.11+tls0.7. TLS and SASL support for Postfix
ii libsasl7 1.5.27-3 Authentication abstraction library.
ii libsasl-digest 1.5.27-3 DIGEST-MD5 module for SASL
ii libsasl-gssapi 1.5.24-15 Pluggable Authentication Modules for SASL -
ii libsasl-krb4-m 1.5.24-15 Pluggable Authentication Modules for SASL -
ii libsasl-module 1.5.27-3 Basic Pluggable Authentication Modules for

$ cat /etc/pam.d/smtp
auth required /lib/security/pam_unix_auth.so
account required /lib/security/pam_unix_acct.so
password required /lib/security/pam_unix_passwd.so
session required /lib/security/pam_unix_session.so

$ cat /etc/postfix/sasl/smtp.conf
pwcheck_method: PAM

(These two above files are duplicated in the chroot jail at
/var/spool/postfix/etc/pam.d/smtp and
/var/spool/postfix/etc/postfix/sasl/smtp.conf - as is the essentially
empty /etc/pam.conf)

$ postconf -n
alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
append_dot_mydomain = yes
biff = no
broken_sasl_auth_clients = yes
command_directory = /usr/sbin
config_directory = /etc/postfix
daemon_directory = /usr/lib/postfix
local_recipient_maps =
luser_relay = m...@address.com
mailbox_command =
mailbox_size_limit = 0
mydestination = my1.host.com, my2.host.com, my3.host.com
myhostname = my.host.com
mynetworks = 127.0.0.0/8, 10.7.11.2/16
myorigin = /etc/mailname
program_directory = /usr/lib/postfix
recipient_delimiter = +
relayhost =
setgid_group = postdrop
smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU)
smtpd_recipient_restrictions = permit_mynetworks,
permit_sasl_authenticated, reject_unauth_destination,
check_relay_domains
smtpd_sasl_auth_enable = yes
smtpd_sasl_local_domain = $mydomain
smtpd_sasl_security_options = noanonymous
queue_directory = /var/spool/postfix

Here's part of what I do to set up the libraries in the chroot jail:
echo "updating chrooted postfix..."
cp -a /lib/security /var/spool/postfix/lib # PAM libs
rm -rf /var/spool/postfix/etc/pam.d
cp -a /etc/pam.d /var/spool/postfix/etc # PAM conf
rm -rf /var/spool/postfix/usr
mkdir /var/spool/postfix/usr /var/spool/postfix/usr/lib
cp -a /usr/lib/libsasl* /var/spool/postfix/usr/lib/
cp -a /usr/lib/sasl /var/spool/postfix/usr/lib # SASL libs

Oh, and to verify that SASL is supported:
$ telnet localhost 25
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
220 mail.hostname.org ESMTP Postfix (Debian/GNU)
EHLO whatever.com
250-oldhat.oldhat.org
250-PIPELINING
250-SIZE 10240000
250-VRFY
250-ETRN
250-AUTH GSSAPI LOGIN PLAIN CRAM-MD5 DIGEST-MD5
250-AUTH=GSSAPI LOGIN PLAIN CRAM-MD5 DIGEST-MD5
250-XVERP
250 8BITMIME

Here's where it gets really weird. When I try to send using Outlook 6
against this machine with the right username and password, this is the
ONLY message that ends up in the log:
Mar 1 12:24:46 hostname postfix/smtpd[18735]: connect from hostname.com[1.2.3.4]

Prior to when I was copying the libraries into the chroot jail, I was
getting messages that said SASL authentication failed. (And "couldn't
initialize PAM libraries" messages) As it is, outlook can't send the
mail and just keeps prompting me for a password until I quit. Outlook
is configured with "My outgoing server requires authentication". I
have also sniffed what outlook is sending and things seem to be in
order on that front.

Also, I've been getting many library errors in my logs that reference
"generic errors" in libkerberos:
Feb 27 17:25:39 hostname postfix/smtpd[29603]: add_plugin(/usr/lib/sasl/libkerberos4.so) failed: generic failure
These show up in auth.log rather than the mail logs.

Any help that anyone could provide would be extremely appreciated.
I've been wrestling with this for 3 days now and I can't get it right.

--
M. David Allen

Wietse

fo...@mothra.dyndns.org:

Wietse Venema spoke forth with the blessed manuscript:

Wietse

Mike Garfias:

Indeed.
That's a particular feature which --being quite paranoid myself sometimes--
I love from Lamont Jones' fine packages.

By following general advice often given in this list, one would first KISS
( Keep It Simple and Stupid ), thus:
- disable chroot in master.cf for, at least, smtpd
- configure PAM
- test

then you might reenable chroot for smtpd if you like.

Keep in mind that, in order to authenticate against /etc/passwd -
/etc/shadow, PAM must be called by a *privileged* ( i.e. belonging to root
) process -- which Postfix's smtpd is not, by any means.
You will need to configure saslauthd to do that ( i'd love to hear from it,
since i didn't manage to get it working -- fortunately i didn't need it,
either ) or else, use SASLDB

HTH

Regards,
J.L.

As explained

>But I'm not particularly comfortable doing it like that I don't
>think. If I chroot it, or if I drop priveleges for the daemon, it
>stops working,

chroot enabled => Postfix can not access /etc/shadow (obviously)
smtpd unprivileged => Postfix can not auth against /etc/shadow through PAM

>and there's not enough information in the logs to tell
>why exactly it's not working. The logging is quite strange - if I
>give the daemon root priveleges but keep it chroot'ed, then I get SASL
>authentication failed messages in my logs.

Cannot access /etc/shadow, as explained

>If it has no root priveleges and is not running chroot'ed, no messages
>show up in the
>logs except the connect from the client. (Not even the disconnect!)

That's simply an authentication failure, which is obviously not logged.
( if the requesting process is not privileged, PAM simply answers "auth
failed" )

>[snip]
>
>Thanks, I will explore this route and seewhat I can come up with.
>
>Is there any reasonable way to create a sasldb and keep it synced with
>/etc/shadow?

Brute force is not feasible ( you would need to "discover" each password by
brute force, then reconstruct sasldb from that )

You could chroot smtpd and copy /etc/shadow to the "jail" ( shivers ).
IIRC, this is as secure as leaving sshd enabled, Wietse said.

I finally did it by authenticating against a different process ( a good job
for TCP: map? ) via unix socket / loopback.
Try "saslauthd -a pam"

>Thanks for the tips

You're welcome!

J.L.

I've been wrestling with SASL, Debian and postfix for a while now, and
I think I've finally gotten it. The key problem was that after
reading a particular news:mailing.postfix.users entry, it appears that
the CRAM-MD5 driver that's in the sasl library always authenticates
against sasldb, even if the sasl library is configured to authenticate
against PAM or whatever.

I've found that this is true. It causes major problems though since a
number of clients (particularly Eudora) always use CRAM-MD5 if it's
available.

The only fix seems to be to delete the /usr/lib/sasl/libcrammd5*
libraries in order to effectively drop support for CRAM-MD5. If you
don't, then you're pretty much lost regardless of what other
configuration is done.

Of course this pretty much sucks since it means you can't do
authentication against non-sasldb sources and support CRAM-MD5 at the
same time, but it doesn't appear to be postfix's fault. Anyway, I've
been having such a hell of time with this, I thought I'd post it so
people who find themselves in my sitation might benefit from it if
they search the archives.

The link to the information relating to the cram-md5 method:

http://groups.google.com/groups?q=group:mailing.postfix.users+insubject:SASL+insubject:authentication+insubject:in+insubject:debian+author:markus.schabel%40tgm.ac.at&hl=en&lr=&ie=UTF-8&oe=UTF-8&selm=b3n98g%241527%241%40FreeBSD.csie.NCTU.edu.tw&rnum=1

Once CRAM-MD5 support is dropped, Eudora and other clients fall back
to AUTH LOGIN which isn't the best, but is better than not working at
all.

CRAM-MD5 relies on having a plain-text password to create the
challenge. If you use an authentication method where your password is in
shadow, or crypt-password in MySQL, then it stands to reason that
CRAM-MD5 won't work.

Since PAM is unlikely to provide plain-text passwords, then maybe the
default for SASL+CRAM-MD5 is saslb, and you'd have to compile it
differently to play the game with, say, MySQL with plaintext
passwords...?

Thinking about this, I went to check the SASL documentation

"Shared secrets mechanisms
=20
The Cyrus SASL library also supports some "shared secret"
authentication methods: CRAM-MD5 and its successor DIGEST-MD5. These
methods rely on the client and the server sharing a "secret", usually a
password. The server generates a challenge and the client a response
proving that it knows the shared secret. This is much more secure than
simply sending the secret over the wire proving that the client knows
it. =20

There's a downside: in order to verify such responses, the server
must keep passwords or password equivalents in a database; if this
database is compromised, it is the same as if all the passwords for the
realm are compromised.
=20
For simplicity sake, the Cyrus SASL library stores plaintext
passwords only in the /etc/sasldb2 database. These passwords are then
shared among all mechanisms which choose to use it. Depending on the
exact database method used (gdbm, ndbm, or db) the file may have
different suffixes or may even have two different files ("sasldb.dir"
and "sasldb.pag"). It is also possible for a server to define it's own
way of storing authentication secrets. Currently, no application is
known to do this."

My reading of this is that you're right: no way of plugging some
authentication DB into SASL for CRAM-MD5...

Regards,

--=20
[-------Fog in Rabat, 11=B0C/52=B0F. Wind: E strength 2. Humidity: 100%--=
----]
Neutron stars are almost unimaginably dense: a teaspoon of neutron star
material weighs a billion tons (1.016 billion tonnes).
[Linux user 170823|XML Weather:www.interceptvector.com|.sig:vim/mutt/perl=
]