Re: Server querying of mechanism needed properties

[Phil Pennock]

On 2012-03-26 at 22:55 +0200, Simon Josefsson wrote:
> Getting it up and running appeared non-trivial to a non-exim hacker like
> me, but eventually I'd like to have a Exim server up and running with
> GNU SASL support for interop testing.  Is there an easy way to run exim
> with a minimal non-/etc configuration and have it listen to some
> non-standard port and accept authentication via GNU SASL?  Preferrably
> it should disconnect or at least fail mail delivery after
> authentication.

Short answer: no.  Longer answer follows; skip to second "cut here" line
to bypass.  (This isn't template text, just making it easy for those
readers who only care about gsasl to bypass all the Exim stuff).

I just shoved up docs for the current git tree, which include
documentation for the GSASL features:
  http://www.exim.org/~pdp/spec-20120327.pdf     (1.9MB)
  http://www.exim.org/~pdp/spec-20120327.txt     (1.5MB)

As of that build, Chapter 38 relates to the GSASL integration.

============================8< cut here >8==============================

Exim's strongly biased towards being the system MTA, the best advice on
running with reduced privilege is to keep it setuid root and set the
"deliver_drop_privilege" option, which locks things in and means that
Exim can't change uid for delivery purposes.

 
http://www.exim.org/exim-html-current/doc/html/spec_html/ch52.html#SECTrunexiwitpri

Because of some security implications with starting Exim with an
alternative config, and the way that Exim re-execs itself normally, we
stomped hard on running from alternative locations as a security measure
(which was proven necessary).

Grab git from git://git.exim.org/exim.git; cd into the "src/" top-level,
and create "Local" as a parent of that.  (Yes, for historical reasons
there's src/src).  gsasl support is now part of the master branch.

You want to build it with TRUSTED_CONFIG_LIST in Local/Makefile set to
point to a file under your control, which defines which other config
files can be set.  Set CONFIGURE_OWNER to reference the uid that can own
the config file.  Avoid setting ALT_CONFIG_PREFIX.  For a runtime user
of "testexim" set EXIM_USER=ref:testexim and likewise for EXIM_GROUP.

Set to point to appropriate paths within the private area:
  SPOOL_DIRECTORY
  LOG_FILE_PATH
  BIN_DIRECTORY
  CONFIGURE_FILE

You should accept the default ROUTER_* and TRANSPORT_* variables, but at
a real bare minimum can use just ROUTER_ACCEPT and TRANSPORT_APPENDFILE.
Keep at least LOOKUP_LSEARCH to have a place to get passwords from; we
have someone who has successfully replaced Cyrus SASL with GSASL in
production by using LOOKUP_DBM and the "dbmjz" lookup type (which only
exists in git).  Point PCRE_LIBS and INCLUDE at the system PCRE library
-- I haven't enabled that one for pkg-config yet (supporting pkg-config
is part of the next release, is in git for much stuff).

Set:
  AUTH_GSASL=yes
  AUTH_GSASL_PC=libgsasl
(where the value of the latter points to whatever pkg-config name you
use for your development installs).  To test layered QoP interactions,
you'll likely need TLS, which I suspect for you will be:
  SUPPORT_TLS=yes
  USE_GNUTLS=yes
  USE_GNUTLS_PC=gnutls

That should let you "make", "make install", although the latter might
still need root for the setuid.


For the Exim configuration, it starts with macros which you can ignore,
then goes into the main section; after that, "begin foo" starts
directives for foo.

This should be minimal while not being an open relay, and still letting
you send email (for testing gsasl client integration, if someone adds
it?).  It's untested but should work; "exim -bV" will catch major syntax
problems in the config file.  There are no spam controls in this, no
safeties against malicious email address attacks, etc.

-----------------------------8< config >8-------------------------------
PASSWORDS_FILE=/path/to/file/with/usercode/password/pairs

deliver_drop_privilege
primary_hostname = test.example.org
daemon_smtp_ports = 2525
domainlist local_domains = @
acl_smtp_rcpt = acl_check_rcpt
rfc1413_query_timeout = 0s

## When you have a TLS cert (SMTP senders to MX do not verify certs
## ever, as there's no consensus on reasonably identity to test for, so
## self-signed or CAcert is fine)
# tls_advertise_hosts = *
# tls_privatekey = /path/to/passwordless/private/key.pem
# tls_certificate = /path/to/public/keycert.pem

begin acl

# This one:
#  * accepts all locally-generated mail not received over SMTP;
#  * accepts mail to a domain in the local_domains domainlist, if it can
#    be delivered;
#  * accepts all mail where the sender has successfully authenticated;
#  * rejects everything else.
#
acl_check_rcpt:
  accept hosts = :
  accept domains = +local_domains
         endpass
         verify = recipient
  accept authenticated = *
  deny   message = relay not permitted

begin routers

dnslookup:
  driver = dnslookup
  domains = ! +local_domains
  transport = remote_smtp
  no_more

bitbucket:
  driver = accept
  transport = discarder

begin transports

discarder:
  driver = appendfile
  file = /dev/null
  user = YOUR_RUNTIME_EXIM_USER

remote_smtp:
  driver = smtp

begin retry
# without a retry configuration, mail not delivered immediately will sit
# in the queue forever; under high load, some mail won't be delivered
# immediately, even though it's going to /dev/null
*                       *               F,2h,15m; G,16h,1h,1.5; F,4d,6h

begin authenticators

digest_md5_via_gsasl:
  driver = gsasl
  public_name = DIGEST-MD5
  server_realm = TEST.EXAMPLE.ORG
  server_password = ${lookup{$auth1}lsearch{PASSWORDS_FILE}{$value}fail}
  server_condition = yes
  server_set_id = ${quote:$auth1}

-----------------------------8< config >8-------------------------------

The "@" in local_domains just references primary_hostname; change to:
  domainlist local_domains = @ : @mx_any
to be able to point multiple MX records at the box to test
authentication with domains.

The file referenced by PASSWORDS_FILE should have lines of "key: value"
where the key is the identifier passed as the authid and the value the
raw password value.  Blank lines and lines starting "#" allowed.

You can have multiple authenticators, you just can't have more than one
with the same public_name.

============================8< cut here >8==============================

> I'm coming back to this issue, but I'm still not settled on what a good
> API would look like.
> 
> How about something like:
> 
>   gsasl_server_properties (ctx, name, &p);
> 
>   #define MAX_PROPS 10
>   typedef struct {
>          int need[MAX_PROPS];
>          int avail[MAX_PROPS];
>          int opt[MAX_PROPS];
>   } gsasl_props;
> 
> The meaning is that there is a list of OR sets of values.  In each
> member of the array, the 'need' list the properties that are needed.
> The 'avail' list the properties that are available for inspection when
> the 'need' properties are called for.  The 'opt' properties are
> additional properties the server can specify to influence operation.

That looks appropriate to me.

> Is this useful?  It doesn't answer your key question directly, but the
> information is in there.

I think it does answer my question.  I have a mechanism name, I can
iterate over the satisfiable conditions and check for each whether I
have sufficient data and raise errors before even starting
authentication if not.

I think that there'll need to be a guarantee that either two "need"s can
not have one be a subset of the other (or identical), or that the
"need"s which ask for the most data must come earlier in the list.

> Maybe a better API is a "meta" accessor for each mechanism,
> e.g. something like this:
> 
>   void *gsasl_mech_meta (ctx, "CRAM-MD5", "server-properties")
> 
> that can be cast into a struct with the necessary information.

That's a lot of library calls back and forth.  I'm happy with your main
proposed solution.  :)

> I think some more brainstorming around this is required.

As a warning in case I go silent: My free time for Exim (and GSASL) is
likely about to almost completely disappear.  :/

If you use IM and want to link up in closer-to-real-time, let me know
and I'll pass you my details.  I tend to not use public IRC these days.

-Phil

pgpSHz3XiJCDR.pgp
Description: PGP signature