Professional Web Applications Themes

sendmail/SMTP-AUTH/PAM Solution!!! - Debian

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 ...

  1. #1

    Default Re: sendmail/SMTP-AUTH/PAM Solution!!!

    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 fish. 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:
    >
    > [url]http://www.ipnet6.org/src/cyrus-sasl-2/doc/sysadmin.html[/url]
    >
    > 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
    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.2.2 (GNU/Linux)

    iD8DBQA/HsDd5hAQwGnDo8QRAlE+AJ9awOuwM3NbuG70+S2KJi/xRACOAgCePpxl
    30ZOzFM2+X+wPOIOVWb5zYg=
    =zhZb
    -----END PGP SIGNATURE-----

    Jeff Wiegley, PhD Guest

  2. #2

    Default Re: sendmail/SMTP-AUTH/PAM Solution!!!

    On 23 Jul 2003 10:07:41 -0700
    "Jeff Wiegley, PhD" <jeffwcyte.com> wrote:
    > 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.
    Sure, no problem. See below for some addenda, though.
    > <snip>
    >
    > 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.
    >
    > <snip>
    If somebody out there knows SASL better than I do, I would also like to
    understand the motivation for this change in behavior (passwords were
    hashed in SASLv1, but not in SASLv2). It would appear that SASL, being a
    crypto package, should be able to implement some kind of hash, even if
    only a simple one, for its password database regardless of the platform.
    But the SASL people are obviously not stupid, so I expect there must be
    something I'm missing.

    Also, since this is being preserved for posterity, I should add two
    more significant points.

    1) SSL/TLS are not "end-to-end encryption" methods as I erroneously
    stated.

    2) The per-service SASL config files (like Sendmail.conf.2) can have
    some further variability to keep you on your toes. Sendmail follows
    the standard, so the following doesn't change what I wrote. But
    should somebody be using that info for other SASL-capable apps, there
    are a couple more hangups.

    The canonical location for per-service config files is
    /usr/lib/sasl2 (Debian symlinks from there to /etc/mail/sasl for
    Sendmail), but that location is not strictly enforced. Apps are free to
    read their SASL config from elsewhere if they desire. Cyrus IMAP, on BSD
    at least (haven't checked out Debian's version), reads its SASL config
    from /etc/imapd.conf. So you have to check the app's docs to figure out
    where the file should live. Furthermore, since the file is pd by the
    app and not by a SASL component per se, the syntax can differ from I
    outlined in the post. Taking Cyrus again, it's config file *does* use
    sasl_pwcheck_method, even though I said that option is obsolete. How?
    Because Cyrus handles the parsing and strips the leading "sasl_" part
    when it hands off the info. So really, it is using just "pwcheck_method"
    as I described, but it doesn't look like it at first. This also means
    that options pertaining to SASL can be mixed in with other non-SASL
    options, since the app chooses which parts to hand off.

    Ah, what fun...
    Todd


    --
    To UNSUBSCRIBE, email to [email]debian-user-requestlists.debian.org[/email]
    with a subject of "unsubscribe". Trouble? Contact [email]listmasterlists.debian.org[/email]
    Todd Pytel Guest

Similar Threads

  1. SMTP SSL StartTLS Auth
    By jeiBean in forum Coldfusion Server Administration
    Replies: 1
    Last Post: July 26th, 10:42 AM
  2. Net::SMTP auth()
    By Dan Muey in forum PERL Beginners
    Replies: 2
    Last Post: October 28th, 09:33 PM
  3. Replies: 2
    Last Post: July 31st, 06:47 AM
  4. smtp.sendmail security
    By John W. Long in forum Ruby
    Replies: 3
    Last Post: July 29th, 01:15 PM
  5. how do I get sendmail SMTP-AUTH to use pam (and not SASL2)?
    By Jeff Wiegley, Ph.D. in forum Debian
    Replies: 5
    Last Post: July 21st, 07:40 AM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139