Todd,
I hope you don't mind but I'm copying your last message
sent to me to the users lists because it did result in a
solution. and its so simple that I want a permanent record
of it in a searchable location.
As anybody reading this will be able to see Todd did an
excellent job figuring out the idiosynchracies of the
interactions of sasl and sendmail, especially the changes
that were made to the syntax and semantics of the
Sendmail.conf.2 file.
I need sendmail to do two things:
1) I need it to provide TLS support. In the sid version of
debian you will need packages: sendmail, libgnutls7,
libssl0.9.7 and probably openssl.
sendmailconfig will detect that you have SSL/TLS
capabilities but will warn you that you need to add
the line:
include(`/etc/mail/tls/starttls.m4')dnl
to the end of /etc/mail/sendmail.mc and /etc/mail/submit.mc
just adding that line will get sendmail to support SSL/TLS
connections (STARTTLS will now be advertised in response to
EHLO.)
2) I needed SMTP-AUTH working. I run smaller sites and want
authentication to be done against the /etc/passwd and
/etc/shadow information (or PAM.) I don't want to maintain
and synchronize multiple credential databases.
sendmail supposedly can use a variety of authentication
methods but the only one that I finally understand a
bit about and got working was saslauth. so you'll need
sasl2-bin, libsasl2-modules.
Now the tricky part. sasl will provide you with
/etc/mail/sasl/Sendmail.conf.2 BUT IT IS CONFIGURED
WRONG!! sendmail or saslauthd from SASL version 2
will not understand the sasl_pwcheck_method lines.
you will need to change it to simply passwd_check.
here's what I have in my /etc/mail/sasl/Sendmail.conf.2:
pwcheck_method: saslauthd
yep just that one line.
now configure saslauthd by editing /etc/default/saslauthd
and change START to yes and you can leave the MECHANISM as
PAM.
run sendmailconfig again. You can just say "y" to the
three questions about reusing your current .mc files and
restarting sendmail; it will preserve the changes you
made.
that will have restarted sendmail. now just
/etc/init.d/saslauthd restart to get the saslauthd restarted
and all should work nicely.
By doing this you will get SMTP-AUTH working with PAM.
Oh here's a good one for you... Why I **REALLY** don't
want to use the sasl2 database... umm /etc/sasldb2
stores passwords IN CLEARTEXT!!! so if somebody hacks
the box they instantly know all my passwords. This is
just stupid.
A quote from the sasl docs:
"For simplicity sake, the Cyrus SASL library stores
plaintext passwords only in the /etc/sasldb2
database."
Umm. What bright idiot though that the best route to
implement something secure was the "simple" way??
At least with plain/login I can keep shadow secret's
hashed and I can accept only pops and imaps to prevent
passwords from being communicated in plaintext.
Thanks for your help!!
- Jeff
On Tue, 2003-07-22 at 00:30, Todd Pytel wrote:
> Hi Jeff,
>
> Got the basics working. There are basically two general problems
> here, elaborated on below...
>
> 1) SASL is non-intuitive.
> 2) Debian's Sendmail.conf.2 is dated.
>
> The (very) long versions...
>
> 1) SASL is non-intuitive.
>
> What you're trying to do (auth against /etc/shadow) seems simple, unless
> you think about it. Think about a regular console login. You enter your
> username, get a password prompt, and enter your password. But before
> that password is checked, it's hashed (MD5, DES, etc.) - otherwise you'd
> be comparing passwords to plain text files, which is obviously a bad
> idea. OK, now think about SMTP-AUTH again. Ideally, you don't want to
> send a password in clear text. You could send a hash, but how do you
> know which one to use? Linux boxes mostly use MD5, old *nix boxes use
> DES, OpenBSD uses Blowfish. There have to be standard hashes defined,
> so the SASL standard defines them - CRAM-MD5 and DIGEST-MD5 (also
> Kerberos stuff and others, but those get more complicated). Great, so
> your mail client will send an MD5 hash. Could you auth that hash
> against /etc/shadow? Yeah, probably. But SASL doesn't - for good
> reasons. First off, many systems don't use MD5 hashes, and the point of
> a hash is that it's "one-way" - you can't get the original password out
> of the hash (without a lot of work) to convert back to the system's
> native format. Second, in the big picture, MD5 is not really that common
> - enterprises use other systems (like Kerberos) that are faster and more
> centralized. Third, creating a SASL mechanism to auth an MD5 against
> shadow would be terribly platform-dependent, given variations in file
> formats and system calls. Finally, large organizations (the ones most
> likely to use SASL) generally want to get users out of the system
> password files unless absolutely necessary. Not everyone needs a real
> UID, a shell, or the ability to own files and parent processes.
> Virtualize the users and let the apps sort it out as necessary. All in
> all, sending a hash against shadow doesn't make nearly as much sense as
> it would immediately appear. So SASL prefers using either a) standard
> and scalable mechanisms like Kerberos or SQL, or b) it's own fast and
> standardized sasldb built off the MD5 standard. (Sidebar: SASLv2 no
> longer hashes passwords in sasldb. Though it uses a hash for the
> communication, it stores the un-hashed password. Why? Don't know, but
> this leads to yet more confusion in understanding old docs.)
>
> That's the hardest part - understanding *why* SASL works as it does.
> >From there on, it makes (mostly) more sense.
>
> So what's a guy to do when he wants to auth against shadow? Well, while
> SASL prefers (a) and (b) mentioned just above, it provides a
> fallback for situations that don't work in the preferred manner. The
> fallback has to be plain text (really Base64 encoded, but effectively
> plain text), since that's the lowest common denominator. Send a plain
> text password, and let the other system do whatever it wants to do with
> it. Somewhat confusingly, there are actually two different plain text
> mechanisms - PLAIN and LOGIN. From what I can tell, those are minor
> protocol differences respecting backward compatibility for *nix and MS
> respectively. PLAIN is technically better, but security-wise, they're
> the same - Base64 encoded text. So if you allow one, you might as
> well allow both. With the PLAIN and LOGIN mechs, you get option c)
> saslauthd. Saslauthd is what's responsible for "doing whatever needs to
> be done" for the individual system - it's basically a way to encapsulate
> specific, privileged code and keep it out of the standard SASL protocol.
> The thing to remember about saslauthd is that it is essentially a plain
> text method - *it's only safe if you have end-to-end encryption (SSL or
> TLS) protecting the exchange*.
>
> Summary: We need plain text authentication, using saslauthd.
>
> 2) Debian's Sendmail.conf is dated.
>
> If it weren't bad enough that SASL is non-intuitive and, arguably,
> confusing, it also just so happens that SASL configuration has changed
> considerably between SASLv1 and SASLv2. Unfortunately, docs relating to
> v1 are much more common on the Net, probably because installations using
> this sort of thing are not prone to quick changes. There's a good page
> on SASLv2 here:
>
> http://www.ipnet6.org/src/cyrus-sasl-2/doc/sysadmin.html
>
> Very important page - wish I had found it earlier. I'm sure it must be
> included in the Debian docs somewhere, but I couldn't find it. The long
> and the short of it is that there are *many* fewer options in the config
> files now. Again, this makes old docs basically worthless. In
> particular, there used to be both pwcheck_method and
> sasl_pwcheck_method. As best as I can tell, this is no longer the case.
> There is now only pwcheck_method, which has 3 theoretical
> specifications, but really only 2:
>
> 1) auxprop - catchall for secure communications. This means auth'ing
> against sasldb via MD5 hashes, or Kerberos, or (your favorite) OPIE/OTP,
> or SQL. It looks like "auxprop_plugin" can be used to specify exactly
> which one to use, but that may be deprecated too... I can't tell. As
> you've seen, this gets confusing when you don't understand why SQL, etc.
> is getting involved. In SASL terms, these are the mechs CRAM-MD5,
> DIGEST-MD5, GSSAPI, KERBEROS-V4, OTP, MYSQL, and a couple other
> oddballs.
>
> 2) saslauthd - catchall for plain-text communications. This will
> require saslauthd to be running with the appropriate "-a" flag. This is
> used by the SASL mechs PLAIN and LOGIN (obsolete).
>
> 3) pwcheck - obsolete. This is, I think, another plain text auth in
> theory. But it's explicitly deprecated in favor of saslauthd. I
> imagine this is the source for the existence of both "pwcheck_method"
> and "sasl_pwcheck_method" in old configs and scripts. This option has
> to be explicitly enabled at SASL compile-time, and most packages won't
> even use it. Would have been better if they had just let it die, IMO...
>
> So Debian's Sendmail.conf.2 is pretty damn misleading. Besides the fact
> that still includes both *pwcheck_method lines, the options listed
> in the comments for "pwcheck_method" are obsolete. Brilliant. The ONLY
> thing you need in Sendmail.conf.2 to auth against shadow is
>
> pwcheck_method: saslauthd
>
> and then make sure you run (as root) "saslauthd -a shadow". You could
> change "-a shadow" to "-a pam" also, but I didn't check it out because
> PAM is a PITA I don't like to mess with and it's not necessary in this
> case anyway.
>
>
>
> Christ, have I really been talking this long and not posted a config
> yet? Seems so. I've attached the archive smtpauth.tgz to this mail.
> It contains two things:
>
> 1) mail.tgz - my entire /etc/mail directory for reference. Like I said
> in the first mail, this stuff is hard enough without all the Debianese
> going on, so I ripped it all out and did everything manually. I'd guess
> Debian's tools and the Makefile will complain if you try to use them - I
> just created sendmail.cf directly from sendmail.mc using m4. The
> default init scripts still work fine, though. Don't get me wrong, I'm
> sure Debian's configuration is fabulous, but it just wasn't what I was
> interested in figuring out right now.
>
> 2) sendmail.mc.com - my .mc file, commented. This is not usable as is,
> because I used #'s instead of dnl's. More readable that way. I also
> regrouped some lines - there's no guarantee that that's OK with m4, so
> refer to the original in mail.tgz.
>
> So that's pretty much the end of the story. As I mention repeatedly in
> the .mc, you still have to get TLS working. I'll leave that part up to
> you.
>
> Cheers,
> Todd
Attachment:
signature.asc
Description: This is a digitally signed message part