[Mailman-Developers] Q: Security checking in wrappers and config file

[Harald Meland]

[Michael Tokarev]

> I looked to mailman wrappers code, and found that it performs some
> strange to me fings.  First of all, it is seemed to be not good idea
> to define uids/gids as numbers inside executable wrappers (for mail
> and www).

These values are derived from whatever GIDs the configure script
finds.  You can specify what group name to use with the
"--with-mail-gid" and "--with-cgi-gid" configure options.

> I think that something caused the current approach when the code was
> developed, but don't know what it was...
> 
> Why not use the following schema:
> 
> * made one config file in well-known place (e.g. /etc/mailman.conf)
>   and require that it writable only by root (maybe)
> * place all the info there (including mail gid, www gid,
>   location of mailman "home" directory etc. (the last one
>   will be PYTHON_PATH; also, it can be read using getpwnam)

Why?  What does this win us over the situation we have now?

The only "advantage" I can see is that you wouldn't have to recompile
Mailman if some of the GIDs Mailman is invoked from change; editing
the config file will suffice.  However, is that really a common enough
occurence that we'd want to require a separate config file for it?

> * do not rely on setgid for mailman home, but instead use real
>   setgid calls

Ummm, I don't think I understand what you mean...

> With current layout, it is not possible to split programs and data.

Not quite true; you can fake a split by substituting symlinks for the
subdirs under $(prefix).

> I want to put all executables into, say, /usr/mailman, and all data
> to /var/[spool/]mailman and /var/log/mailman (and mount /usr
> read-only).  Having config file it is simple.
> 
> Also, with current approach, many files will be owned by some
> strange users when mailman operates.  For example, config.db file
> owned by nobody (run from www) or whatether owner when run from MTA,
> the same cab be with logs.  This is potentially unsecure, as, e.g.,
> any other cgi script can read _and_ write this config file as a
> result, not only mailman group.  Yes, rewriting is not very good
> (not an atomic operation), but I prefer security here...

Ummm, I still don't follow you -- are you saying that we should use
setuid instead of setgid stuff?

As for other cgi scripts being able to write lists' config.db files:
Unless your web server user is a member of the mailman group,
non-mailman-setgid cgi scripts may be stopped from accessing
Mailman-internal data by

  chgrp mailman $(prefix)/lists
  chmod o-rwx $(prefix)/lists

etc. (I think -- this is untested).

> And some more thoughts.
> Many MTAs sets environment variables when delivering to programs.
> For example, postfix sets LOGNAME to recipient name, DOMAIN to
> part of recipient address after @, FROM to envelope address
> and so on, and those variables are _safer_ to use (in case of
> postfix) than information from mail contents (with both sides --
> MTA can have more info available about real person who sends this
> mail, based on, say, smtp AUTH commands, and, in case of postfix,
> those values are already parsed by intelligent mechanism and with
> all strange/funny/control characters removed).
> Is it possible candidate to enhancement to include usage of those
> variables?

Only if it would be a) safe and b) not too MTA-specific.  In the
example you provide, I don't think those two criteria are satisfied --
I'd either have to _explicitly_ tell Mailman that the MTA delivering
to it is Postfix, or risk using heuristics to determine what MTA is
doing the delivery.  I suppose heuristics might easily be fooled if I
pass similar environment variables on to e.g. an Exim daemon.

> P.S. I'm new to this list... :)

Welcome!  Hopefully me being rather sceptic to the changes you are
proposing aren't ruining the first impression ;)
-- 
Harald