OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
Subject: Re: SASL for fun and profit
From: Liviu Daia (Liviu.Daiaimar.ro)
Date: Tue May 16 2000 - 18:03:48 CDT

On 16 May 2000, Wietse Venema <wietseporcupine.org> wrote:
> Liviu Daia:
> > I played a little with the new SASL feature (snapshot 20000511,
> > cyrus-sasl 1.5.21). What follows is a brain dump of my findings, in
> > no particular order.
> >
> > (1) Both the server and the client seem to work fine, with the
> > notable exception that smtpd on the server side tend to bail out
> > with the message "no SASL authentication mechanisms" if several
> > messages arrive at the same time. Looking at the sources, this
> > doesn't appear to be Postfix' fault.
>
> I delete my comments on this one...

    Sorry, not everyone can afford to run *BSD at work. :-) But I did
run my tests on a DEC Alpha, not a crappy PC.

[...]
> > (3) On the client side, the mechanism that matches the MX hosts to
> > the user/password pairs is IMO way too picky. Basically, if you
> > want to make sure an AUTH request is issued when sending messages
> > to a given site, you need to know _all_ "official" names of _all_
> > MX hosts for the target domain, and list them in the lhs of the
> > password map. A better approach would be (still IMO) to try to
> > match the target address first, then the MX hosts, and for each of
> > them do the same thing Postfix does when checking access tables: try
> > exact match, subdomains, and IP patterns. Does this make sense?
>
> Depends on how SASL would be used. Presumably, all MX hosts
> responsible for a given destination would be administered by the same
> people. SASL would not work well if the primary is run by me and the
> backup is run by my ISP.
>
> So, it would make sense to look for a per-destination key/password
> before looking for a per-host one.

    Hmm. Put like this, it probably makes sense both ways --- but I
don't think the precedence really matters here: I'd normally put either
a domain or a list of MX hosts in the password map, not both.

> > (4) Given that the permissions on the "postmapped" password db are
> > now just as important as the ones on the text source, it would
> > make sense for postmap to stat the source file, and use the same
> > permissions when creating the dbs, if possible. It can be done with
> > dbm and Berkeley DB, and it isn't applicable to MySQL and regexp
> > maps. Didn't check the other types.
>
> Permissions can be fixed somewhat by tweaking the umask. In addition
> to file permissions, there is file ownership. Having to chown fils is
> ugly.

    Please note I'm referring to creating the (client-side) password
db, not the (server-side) sasldb. The ownership doesn't really matter,
since postmap is normally run as root, and Postfix opens the maps as
root too (CMIIW). I'm just asking for a safety net, since not everyone
runs with "umask 077", even as root.

> > (5) When using verbose logging (f.i. with $debug_peer_list) the
> > password is written to the logs in clear text. Not a huge security
> > issue, but still.
>
> That can't change. The verbose log is for debugging. Having to run gdb
> on the running process is too intrusive.
[...]

    I can see your point, but the permissions on the log files are not
necessarily the same as the ones on the password map. As somebody else
pointed out, this should be at least documented.

    Regards,

    Liviu Daia 

-- 
Dr. Liviu Daia               e-mail:   Liviu.Daiaimar.ro
Institute of Mathematics     web page: http://www.imar.ro/~daia
of the Romanian Academy      PGP key:  http://www.imar.ro/~daia/daia.asc